Re: unattended-upgrades by default

[Steve McIntyre]

Holger Levsen wrote:
>On Fri, Jan 06, 2017 at 02:13:58PM +0100, Julian Andres Klode wrote:
>> Two months ago, Steve wrote:
>> > * enable it for installation via d-i by default. At installation
>> [it being unattended-upgrades]
>> What's the status of this? I do not like this idea, it interacts
>> poorly with desktops which handle upgrades via PackageKit 
>
>can't this be solved by PackageKit breaking unattended-upgrades or
>providing a new meta-package "default-upgrade-mechanism", which could
>also be provided by the unattended-upgrades package?

That's the kind of thing I was thinking of, yes. I'm proposing
unattended-upgrades as a default only for systems that don't already
have their own mechanism for upgrades...

-- 
Steve McIntyre, Cambridge, UK.st...@einval.com
< sladen> I actually stayed in a hotel and arrived to find a post-it
  note stuck to the mini-bar saying "Paul: This fridge and
  fittings are the correct way around and do not need altering"

Re: unattended-upgrades by default

[Steve McIntyre]

Lars Wirzenius wrote:
>
>Distro development is difficult, let's go shopping.
>
>Sarcasm aside, here's a summary of the situation, as I understand it.
>tldr: let's not despair, we have a mostly technical problem that's
>simpler to solve than choosing a default editor, we can handle this.
>
>We'd like most hosts running Debian to get security updates as soon as
>possible after the updates have been received. This would make Debian
>users more secure, and also the whole of the Internet. A simplistic
>approach (unattended-upgrades plus automatic rebooting) is not going
>to work. However, we can do less simplistic approaches, we just need
>to design and implement those.
>
>This is a big change, and it's way too late in the stretch cycle to
>make it now. However we do it, we'll want months of use on real hosts
>to find corner cases and special cases. It will have to wait for the
>next release of Debian. Thus we're not in any great hurry and can take
>the necessary time to do this right.
>
>So far we've identified at least cloud images as a case where
>automatic upgrades and related reboots are probably not particularly
>painful. Even for those there's going to be cases where they're
>unwanted. However, having the necessary software to do upgrades +
>reboots and enabling them would still be a good default. Add an easy
>and well-documented way to disable upgrades, and we should be good.
>
>Arguably the same approach should work on any system without a
>graphical desktop installed. On those, using the interactive features
>for notifying the user is probably good enough, with the exception of
>hosts where a desktop is installed but never used, and the server
>solution is enough for those.

Thanks Lars - that's an excellent summary of the situation. I was
hoping to have made some progress on unattended-upgrades already, but
$stuff... :-/

What we *will* try to do is enable it for cloud images for Stretch.

-- 
Steve McIntyre, Cambridge, UK.st...@einval.com
< sladen> I actually stayed in a hotel and arrived to find a post-it
  note stuck to the mini-bar saying "Paul: This fridge and
  fittings are the correct way around and do not need altering"

Re: unattended-upgrades by default

[Lars Wirzenius]

On Sat, Jan 07, 2017 at 12:04:54PM +0100, Santiago Vila wrote:
> Now we can't be the Universal OS, no matter what we do :-)

Distro development is difficult, let's go shopping.

Sarcasm aside, here's a summary of the situation, as I understand it.
tldr: let's not despair, we have a mostly technical problem that's
simpler to solve than choosing a default editor, we can handle this.

We'd like most hosts running Debian to get security updates as soon as
possible after the updates have been received. This would make Debian
users more secure, and also the whole of the Internet. A simplistic
approach (unattended-upgrades plus automatic rebooting) is not going
to work. However, we can do less simplistic approaches, we just need
to design and implement those.

This is a big change, and it's way too late in the stretch cycle to
make it now. However we do it, we'll want months of use on real hosts
to find corner cases and special cases. It will have to wait for the
next release of Debian. Thus we're not in any great hurry and can take
the necessary time to do this right.

So far we've identified at least cloud images as a case where
automatic upgrades and related reboots are probably not particularly
painful. Even for those there's going to be cases where they're
unwanted. However, having the necessary software to do upgrades +
reboots and enabling them would still be a good default. Add an easy
and well-documented way to disable upgrades, and we should be good.

Arguably the same approach should work on any system without a
graphical desktop installed. On those, using the interactive features
for notifying the user is probably good enough, with the exception of
hosts where a desktop is installed but never used, and the server
solution is enough for those.

-- 
I want to build worthwhile things that might last. --joeyh


signature.asc
Description: PGP signature

Re: unattended-upgrades by default

[Santiago Vila]

On Fri, Jan 06, 2017 at 02:29:12PM -0800, Nikolaus Rath wrote:
> On Jan 06 2017, Santiago Vila  wrote:
> > If we want to be the Universal OS, we can't assume that any time
> > (not chosen by the user) is ok to do an upgrade.
> 
> If we want to be the Universal OS, we can't assume that users will
> explicitly trigger an install of security upgrades either. Nor can we
> assume that running without security updates is acceptable.
> 
> What now?

Now we can't be the Universal OS, no matter what we do :-)

Thanks.

Re: unattended-upgrades by default

[Holger Levsen]

On Fri, Jan 06, 2017 at 02:13:58PM +0100, Julian Andres Klode wrote:
> Two months ago, Steve wrote:
> > * enable it for installation via d-i by default. At installation
> [it being unattended-upgrades]
> What's the status of this? I do not like this idea, it interacts
> poorly with desktops which handle upgrades via PackageKit 

can't this be solved by PackageKit breaking unattended-upgrades or
providing a new meta-package "default-upgrade-mechanism", which could
also be provided by the unattended-upgrades package?


-- 
cheers,
Holger


signature.asc
Description: Digital signature

Re: unattended-upgrades by default

[Paul Wise]

On Sat, Jan 7, 2017 at 6:29 AM, Nikolaus Rath wrote:

> What now?

Clearly the answer of unattended-upgrades or not is situation
dependent and the solution should depend on who is running Debian in
what context.

Desktop users should get whatever UI is available for the particular
desktop that is installed that installs upgrades on shutdown and
suggests upgrades when available.

Cloud users should get unattended-upgrades by default.

etc

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Re: unattended-upgrades by default

[Nikolaus Rath]

On Jan 06 2017, Santiago Vila  wrote:
> If we want to be the Universal OS, we can't assume that any time
> (not chosen by the user) is ok to do an upgrade.

If we want to be the Universal OS, we can't assume that users will
explicitly trigger an install of security upgrades either. Nor can we
assume that running without security updates is acceptable.

What now?

(Sorry for not being constructive, but these "Universal OS" arguments
can really be used to argue for and against anything).


Best,
-Nikolaus


-- 
GPG encrypted emails preferred. Key id: 0xD113FCAC3C4E599F
Fingerprint: ED31 791B 2C5C 1613 AF38 8B8A D113 FCAC 3C4E 599F

 »Time flies like an arrow, fruit flies like a Banana.«

Re: unattended-upgrades by default

[Santiago Vila]

On Fri, Jan 06, 2017 at 02:13:58PM +0100, Julian Andres Klode wrote:
> Two months ago, Steve wrote:
> > * enable it for installation via d-i by default. At installation
> [it being unattended-upgrades]
> 
> What's the status of this? I do not like this idea, it interacts
> poorly with desktops which handle upgrades via PackageKit (which
> is the default) and since there are locking races in apt invoking
> dpkg, it's not really a safe thing to do anyway, causing issues
> like https://bugs.debian.org/850417
> 
> I'd really like to default this to disabled, and add a warning
> about how it interacts with other systems and that people should
> take care running apt manually when the unattended upgrades would
> run, as that can break things.

I don't like it either.

In addition to the reasons already explained, bandwidth is a precious
resource that should not become mostly unavailable at random times by
default.

A sudden drop in available bandwidth could be as inappropriate as an
anti-virus popping up. Imagine that happening during a presentation
in which you expect all bandwidth to be available.

If we want to be the Universal OS, we can't assume that any time
(not chosen by the user) is ok to do an upgrade.

Thanks.

Re: unattended-upgrades by default

[Julian Andres Klode]

Two months ago, Steve wrote:
> * enable it for installation via d-i by default. At installation
[it being unattended-upgrades]

What's the status of this? I do not like this idea, it interacts
poorly with desktops which handle upgrades via PackageKit (which
is the default) and since there are locking races in apt invoking
dpkg, it's not really a safe thing to do anyway, causing issues
like https://bugs.debian.org/850417

I'd really like to default this to disabled, and add a warning
about how it interacts with other systems and that people should
take care running apt manually when the unattended upgrades would
run, as that can break things.

I'm not subscribed to -devel, so please CC me on replies.

-- 
Debian Developer - deb.li/jak | jak-linux.org - free software dev
  |  Ubuntu Core Developer |
When replying, only quote what is necessary, and write each reply
directly below the part(s) it pertains to ('inline').  Thank you.

Re: unattended-upgrades by default?

[Ben Hutchings]

On Wed, 2016-12-28 at 04:13 +, Scott Kitterman wrote:
> 
> On December 27, 2016 11:10:55 PM EST, Adam Borowski  
> wrote:
> > On Wed, Dec 28, 2016 at 04:04:21AM +, Scott Kitterman wrote:
> > > > FTR, it's #739636.
> > > > 
> > > 
> > > Postfix has no way to know it's temporary, so I think a temporary
> > 
> > error
> > > would be wrong.
> > 
> > It's easy to tell apart "can't connect to SQL" from "query succeeded
> > and
> > returned 'no such user'".
> 
> That assumes it will eventually be turned back on.  Temporary versus
> permanent shutdown is what you can't distinguish.

MTAs should always assume a failure is temporary, if they can't tell. 
If the failure is really permanent this delays bouncing to the point
that the sender times-out, but that is much less bad than the opposite
error of bouncing on a temporary error.

Ben.

-- 
Ben Hutchings
No political challenge can be met by shopping. - George Monbiot



signature.asc
Description: This is a digitally signed message part

Re: unattended-upgrades by default?

[Paul van der Vlis]

Op 26-12-16 om 23:44 schreef Paul Wise:
> On Tue, Dec 27, 2016 at 12:35 AM, Paul van der Vlis wrote:
> 
>> I use a script on a few servers to realize this, it's not perfect:
>> http://vandervlis.nl/files/updateafter
> 
> It might be interesting to contribute this to unattended-upgrades.

I use the script for 8 months now, and it works. But I've seen a few
times this kind of errors, what I had to repair manually. So it's not
perfect.


mv: './save/php-gettext_1.0.11-1_all.deb' and
'save/php-gettext_1.0.11-1_all.deb' are the same file


>> I use "at" to reboot very early in the morning:
> 
> /etc/apt/apt.conf.d/50unattended-upgrades:
> Unattended-Upgrade::Automatic-Reboot-Time "02:00";

Ah!  But not sure I would like it to be that the default. But no big
problems with it, it makes you think about rebooting.

With regards,
Paul van der Vlis.





-- 
Paul van der Vlis Linux systeembeheer Groningen
https://www.vandervlis.nl/

Re: unattended-upgrades by default?

[Adam Borowski]

On Wed, Dec 28, 2016 at 04:13:13AM +, Scott Kitterman wrote:
> 
> 
> On December 27, 2016 11:10:55 PM EST, Adam Borowski  
> wrote:
> >On Wed, Dec 28, 2016 at 04:04:21AM +, Scott Kitterman wrote:
> >> >FTR, it's #739636.
> >> >
> >> Postfix has no way to know it's temporary, so I think a temporary error
> >> would be wrong.
> >
> >It's easy to tell apart "can't connect to SQL" from "query succeeded and
> >returned 'no such user'".
> 
> That assumes it will eventually be turned back on.  Temporary versus
> permanent shutdown is what you can't distinguish.

It should be treated akin to "no target MXes are reachable" -- ie, a
temporary error that is considered permanent once a timeout has been
reached.  Retries and the timeout are implemented and configured by the
sending server.


Meow!
-- 
Autotools hint: to do a zx-spectrum build on a pdp11 host, type:
  ./configure --host=zx-spectrum --build=pdp11

Re: unattended-upgrades by default?

[Scott Kitterman]

On December 27, 2016 11:10:55 PM EST, Adam Borowski  wrote:
>On Wed, Dec 28, 2016 at 04:04:21AM +, Scott Kitterman wrote:
>> >FTR, it's #739636.
>> >
>> Postfix has no way to know it's temporary, so I think a temporary
>error
>> would be wrong.
>
>It's easy to tell apart "can't connect to SQL" from "query succeeded
>and
>returned 'no such user'".

That assumes it will eventually be turned back on.  Temporary versus permanent 
shutdown is what you can't distinguish.

Scott K

Re: unattended-upgrades by default?

[Adam Borowski]

On Wed, Dec 28, 2016 at 04:04:21AM +, Scott Kitterman wrote:
> >FTR, it's #739636.
> >
> Postfix has no way to know it's temporary, so I think a temporary error
> would be wrong.

It's easy to tell apart "can't connect to SQL" from "query succeeded and
returned 'no such user'".

-- 
Autotools hint: to do a zx-spectrum build on a pdp11 host, type:
  ./configure --host=zx-spectrum --build=pdp11

Re: unattended-upgrades by default?

[Scott Kitterman]

On December 27, 2016 1:26:24 PM EST, Samuel Thibault <sthiba...@debian.org> 
wrote:
>Ian Jackson, on Sun 25 Dec 2016 23:45:37 +, wrote:
>> Samuel Thibault writes ("Re: unattended-upgrades by default?"):
>> > SZALAY Attila, on Sun 25 Dec 2016 20:54:26 +0100, wrote:
>> > > If we replace postgresql with postfix, that is much more closer
>to the
>> > > standard. And I guess, that postgresql is just a "misspelling".
>> > 
>> > Ew. Yes, sure :)
>> 
>> Oh!  Well, reading it again then, I think this is a bug (quite a
>> serious bug, since it leads to incorrect bouncing of mail) in the
>> postfix/mysql integration.
>
>FTR, it's #739636.
>
Postfix has no way to know it's temporary, so I think a temporary error would 
be wrong.

Better to have postfix notice that a map type has been pulled out from under it 
and stop (what you have to do by hand now).

Scott K

Re: unattended-upgrades by default?

[Samuel Thibault]

Ian Jackson, on Sun 25 Dec 2016 23:45:37 +, wrote:
> Samuel Thibault writes ("Re: unattended-upgrades by default?"):
> > SZALAY Attila, on Sun 25 Dec 2016 20:54:26 +0100, wrote:
> > > If we replace postgresql with postfix, that is much more closer to the
> > > standard. And I guess, that postgresql is just a "misspelling".
> > 
> > Ew. Yes, sure :)
> 
> Oh!  Well, reading it again then, I think this is a bug (quite a
> serious bug, since it leads to incorrect bouncing of mail) in the
> postfix/mysql integration.

FTR, it's #739636.

Samuel

Re: unattended-upgrades by default?

[Paul Wise]

On Tue, Dec 27, 2016 at 12:35 AM, Paul van der Vlis wrote:

> I use a script on a few servers to realize this, it's not perfect:
> http://vandervlis.nl/files/updateafter

It might be interesting to contribute this to unattended-upgrades.

> I use "at" to reboot very early in the morning:

/etc/apt/apt.conf.d/50unattended-upgrades:
Unattended-Upgrade::Automatic-Reboot-Time "02:00";

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Re: unattended-upgrades by default?

[Paul van der Vlis]

Op 25-12-16 om 01:43 schreef Paul Wise:
> On Sun, Dec 25, 2016 at 8:34 AM, Paul van der Vlis wrote:
> 
>> I am doing this myself already on desktop systems so I have some
>> experiences with it.
> 
> Thanks for sharing your experience.
> 
>> What I would really like is a mechanism where the user can tune after
>> how many days the upgrade will occur. Maybe a default could be after 2
>> days. People who like to have faster updates can change this to 0 days,
>> and this people do extra testing of the updates. When big problems occur
>> with an update, the installation of the update should be stopped in some
>> way for the people who have set it at 2 days.
> 
> How do you propose to transmit the info about problematic updates from
> early testers to folks who update later?

I think those users can contact the security team. The security team
could remove or replace a security update, or give information.

Other people can also share information about experiences with the
update, so there is already information on the internet if you use the
2-day default.

I use a script on a few servers to realize this, it's not perfect:
http://vandervlis.nl/files/updateafter

>> It would be nice to have a way to configure a notice (by e-mail?) in
>> case of an error apt or dpkg error.
> 
> /etc/apt/apt.conf.d/50unattended-upgrades:
> Unattended-Upgrade::Mail "root";
> Unattended-Upgrade::MailOnlyOnError "true";

Thanks.

>> I would like something as "apt-get update; apt-get dist-upgrade".
>> So not only "apt-get upgrade", and for everything in sources.list, so
>> not only for security updates. I would like to go from Debian 9.1 to
>> 9.2, but not from Debian 9 to 10.
> 
> /etc/apt/apt.conf.d/50unattended-upgrades:
> Set Unattended-Upgrade::Origins-Pattern to match which packages you
> want to upgrade.

I use "*" and that works fine, I would like it as default.
People who do not want it have many ways to change it.

I am not sure, but if you only use "apt-get update; apt-get upgrade" I
expect you do not have a secure system anymore after some time.

>> Using a program what has been upgraded can give strange problems. I have
>> seen this e.g. with e-mail clients and browsers. I would like it when
>> desktop users could get a message that programs has to be restarted.
>> Not sure this is important for servers too, I would think so.
> 
> apt install needrestart needrestart-session

Thanks, I will study that.

>> I don't think it's an good idea to enable automatic reboots by default.
> 
> I think we either need a Linux kernel livepatch service or automatic reboots.

I would like a kernel livepatch, but it's not there at the moment.

I don't like automatic reboots as a default, but if many people wants
them I can live with it, when I can turn them off.

I use "at" to reboot very early in the morning:
---
TIJD="5:00"
MAIL="p...@vandervlis.nl"

echo "$HOSTNAME is rebooted on $TIJD" | mail -s "$HOSTNAME is rebooted
on $TIJD" $MAIL
echo "mail -s '$HOSTNAME becomes rebooted now' $MAIL; reboot" | at $TIJD
--

With regards,
Paul van der Vlis


-- 
Paul van der Vlis Linux systeembeheer Groningen
https://www.vandervlis.nl/

Re: unattended-upgrades by default?

[Paul van der Vlis]

Op 25-12-16 om 06:36 schreef Samuel Thibault:
> Paul van der Vlis, on Sun 25 Dec 2016 01:34:15 +0100, wrote:
>> I would like it when
>> desktop users could get a message that programms has to be restarted.
>> Not sure this is important for servers too, I would think so.
> 
> In a mail server we have, the mysql upgrades are problematic: while the
> sql server is off, postgresql reports that mailboxes (whose entries are
> stored in the sql database) don't exist, i.e. a permanent fatal error,
> and mails then get lost. We haven't found how to make postgresql return
> a temporary error instead, and so we have to be careful, when upgrading
> mysql, to keep postgresql stopped until mysql is restarted.

If you upgrade a program what's running, there is a difference between
what's in memory and what's on the disk. Sometimes this gives problems,
and it would be good the get a message that the program has to be
restarted. That is what I wanted to say.

With regards,
Paul van der Vlis.



-- 
Paul van der Vlis Linux systeembeheer Groningen
https://www.vandervlis.nl/

Re: unattended-upgrades by default?

[Ian Jackson]

Samuel Thibault writes ("Re: unattended-upgrades by default?"):
> SZALAY Attila, on Sun 25 Dec 2016 20:54:26 +0100, wrote:
> > If we replace postgresql with postfix, that is much more closer to the
> > standard. And I guess, that postgresql is just a "misspelling".
> 
> Ew. Yes, sure :)

Oh!  Well, reading it again then, I think this is a bug (quite a
serious bug, since it leads to incorrect bouncing of mail) in the
postfix/mysql integration.

Ian.

-- 
Ian Jackson <ijack...@chiark.greenend.org.uk>   These opinions are my own.

If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.

Re: unattended-upgrades by default?

[Samuel Thibault]

SZALAY Attila, on Sun 25 Dec 2016 20:54:26 +0100, wrote:
> Hi All,
> 
> On Sun, 2016-12-25 at 08:18 +0100, Samuel Thibault wrote:
> > Scott Kitterman, on Sun 25 Dec 2016 01:27:58 -0500, wrote:
> > > On Sunday, December 25, 2016 06:36:52 AM Samuel Thibault wrote:
> > > > Paul van der Vlis, on Sun 25 Dec 2016 01:34:15 +0100, wrote:
> > > > > I would like it when
> > > > > desktop users could get a message that programms has to be
> > > > > restarted.
> > > > > Not sure this is important for servers too, I would think so.
> > > > 
> > > > In a mail server we have, the mysql upgrades are problematic:
> > > > while the
> > > > sql server is off, postgresql reports that mailboxes (whose
> > > > entries are
> > > > stored in the sql database) don't exist, i.e. a permanent fatal
> > > > error,
> > > > and mails then get lost. We haven't found how to make postgresql
> > > > return
> > > > a temporary error instead, and so we have to be careful, when
> > > > upgrading
> > > > mysql, to keep postgresql stopped until mysql is restarted.
> > > 
> > > That's hardly a standard situation.
> > 
> > Sure.
> 
> If we replace postgresql with postfix, that is much more closer to the
> standard. And I guess, that postgresql is just a "misspelling".

Ew. Yes, sure :)

Samuel

Re: unattended-upgrades by default?

[SZALAY Attila]

Hi All,

On Sun, 2016-12-25 at 08:18 +0100, Samuel Thibault wrote:
> Scott Kitterman, on Sun 25 Dec 2016 01:27:58 -0500, wrote:
> > On Sunday, December 25, 2016 06:36:52 AM Samuel Thibault wrote:
> > > Paul van der Vlis, on Sun 25 Dec 2016 01:34:15 +0100, wrote:
> > > > I would like it when
> > > > desktop users could get a message that programms has to be
> > > > restarted.
> > > > Not sure this is important for servers too, I would think so.
> > > 
> > > In a mail server we have, the mysql upgrades are problematic:
> > > while the
> > > sql server is off, postgresql reports that mailboxes (whose
> > > entries are
> > > stored in the sql database) don't exist, i.e. a permanent fatal
> > > error,
> > > and mails then get lost. We haven't found how to make postgresql
> > > return
> > > a temporary error instead, and so we have to be careful, when
> > > upgrading
> > > mysql, to keep postgresql stopped until mysql is restarted.
> > 
> > That's hardly a standard situation.
> 
> Sure.

If we replace postgresql with postfix, that is much more closer to the
standard. And I guess, that postgresql is just a "misspelling".

Personally I use ldap to store the domains and the email addresses too.

Re: unattended-upgrades by default?

[Philipp Kern]

On 25.12.2016 08:18, Samuel Thibault wrote:
> Yes, but that's a data point to have in mind: blindly upgrading software
> is not always without consequences.

Do we actually communicate a proper way of running services on a Debian
machine, with services coming from Debian packages? If so, what is it?

It seems to me that what could be sensible is pinning locally installed
packages in a way that they are not upgraded by default and instead
would then be upgraded by hand in a maintenance window. Otherwise you
risk outages by synchronization between machines or because database
servers should not simply be restarted while clients are actively using
them.

I can see how it's slightly less dangerous with stateless services like
DNS, where people might just not bother.

Kind regards
Philipp Kern

Re: unattended-upgrades by default?

[Samuel Thibault]

Scott Kitterman, on Sun 25 Dec 2016 01:27:58 -0500, wrote:
> On Sunday, December 25, 2016 06:36:52 AM Samuel Thibault wrote:
> > Paul van der Vlis, on Sun 25 Dec 2016 01:34:15 +0100, wrote:
> > > I would like it when
> > > desktop users could get a message that programms has to be restarted.
> > > Not sure this is important for servers too, I would think so.
> > 
> > In a mail server we have, the mysql upgrades are problematic: while the
> > sql server is off, postgresql reports that mailboxes (whose entries are
> > stored in the sql database) don't exist, i.e. a permanent fatal error,
> > and mails then get lost. We haven't found how to make postgresql return
> > a temporary error instead, and so we have to be careful, when upgrading
> > mysql, to keep postgresql stopped until mysql is restarted.
> 
> That's hardly a standard situation.

Sure.

> I don't think configurations like this 
> are particularly relevant to what should be in the default install.

Yes, but that's a data point to have in mind: blindly upgrading software
is not always without consequences.

Samuel

Re: unattended-upgrades by default?

[Scott Kitterman]

On Sunday, December 25, 2016 06:36:52 AM Samuel Thibault wrote:
> Paul van der Vlis, on Sun 25 Dec 2016 01:34:15 +0100, wrote:
> > I would like it when
> > desktop users could get a message that programms has to be restarted.
> > Not sure this is important for servers too, I would think so.
> 
> In a mail server we have, the mysql upgrades are problematic: while the
> sql server is off, postgresql reports that mailboxes (whose entries are
> stored in the sql database) don't exist, i.e. a permanent fatal error,
> and mails then get lost. We haven't found how to make postgresql return
> a temporary error instead, and so we have to be careful, when upgrading
> mysql, to keep postgresql stopped until mysql is restarted.

That's hardly a standard situation.  I don't think configurations like this 
are particularly relevant to what should be in the default install.

Scott K

Re: unattended-upgrades by default?

[Samuel Thibault]

Paul van der Vlis, on Sun 25 Dec 2016 01:34:15 +0100, wrote:
> I would like it when
> desktop users could get a message that programms has to be restarted.
> Not sure this is important for servers too, I would think so.

In a mail server we have, the mysql upgrades are problematic: while the
sql server is off, postgresql reports that mailboxes (whose entries are
stored in the sql database) don't exist, i.e. a permanent fatal error,
and mails then get lost. We haven't found how to make postgresql return
a temporary error instead, and so we have to be careful, when upgrading
mysql, to keep postgresql stopped until mysql is restarted.

Samuel

Re: unattended-upgrades by default?

[Paul Wise]

On Sun, Dec 25, 2016 at 8:34 AM, Paul van der Vlis wrote:

> I am doing this myself already on desktop systems so I have some
> experiences with it.

Thanks for sharing your experience.

> What I would really like is a mechanism where the user can tune after
> how many days the upgrade will occur. Maybe a default could be after 2
> days. People who like to have faster updates can change this to 0 days,
> and this people do extra testing of the updates. When big problems occur
> with an update, the installation of the update should be stopped in some
> way for the people who have set it at 2 days.

How do you propose to transmit the info about problematic updates from
early testers to folks who update later?

> It would be nice to have a way to configure a notice (by e-mail?) in
> case of an error apt or dpkg error.

/etc/apt/apt.conf.d/50unattended-upgrades:
Unattended-Upgrade::Mail "root";
Unattended-Upgrade::MailOnlyOnError "true";

> I would like something as "apt-get update; apt-get dist-upgrade".
> So not only "apt-get upgrade", and for everything in sources.list, so
> not only for security updates. I would like to go from Debian 9.1 to
> 9.2, but not from Debian 9 to 10.

/etc/apt/apt.conf.d/50unattended-upgrades:
Set Unattended-Upgrade::Origins-Pattern to match which packages you
want to upgrade.

> Using a program what has been upgraded can give strange problems. I have
> seen this e.g. with e-mail clients and browsers. I would like it when
> desktop users could get a message that programs has to be restarted.
> Not sure this is important for servers too, I would think so.

apt install needrestart needrestart-session

> I don't think it's an good idea to enable automatic reboots by default.

I think we either need a Linux kernel livepatch service or automatic reboots.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Re: unattended-upgrades by default?

[Paul van der Vlis]

Op 03-11-16 om 19:47 schreef Steve McIntyre:

> Thoughts?

I am doing this myself allready on desktop systems so I have some
experiences with it.

What I would really like is a mechanism where the user can tune after
how many days the upgrade will occur. Maybe a default could be after 2
days. People who like to have faster updates can change this to 0 days,
and this people do extra testing of the updates. When big problems occur
with an update, the installation of the update should be stopped in some
way for the people who have set it at 2 days.

It would be nice to have a way to configure a notice (by e-mail?) in
case of an error apt or dpkg error.

I would like something as "apt-get update; apt-get dist-upgrade".
So not only "apt-get upgrade", and for everything in sources.list, so
not only for security updates. I would like to go from Debian 9.1 to
9.2, but not from Debian 9 to 10.

Using a program what has been upgraded can give strange problems. I have
seen this e.g. with e-mail clients and browsers. I would like it when
desktop users could get a message that programms has to be restarted.
Not sure this is important for servers too, I would think so.

I don't think it's an good idea to enable automatic reboots by default.

With regards,
Paul van der Vlis.

-- 
Paul van der Vlis Linux systeembeheer Groningen
https://www.vandervlis.nl/

Re: unattended-upgrades by default?

[Paul Wise]

On Wed, 2016-11-09 at 23:06 +0200, Adrian Bunk wrote:

> Any "solution" for the reboot problem that assumes that there is a
> user who regularly logs into the machine misses the problem.

Any solution that is the same for every device is completely wrong.

Cloud images should probably auto-reboot ASAP since they will mostly be
unattended. User desktops, laptops, phones will often have a logged-in
user who can be asked to reboot. Home routers and servers with a low
period in user activity should be auto-rebooted during the period of
low user activity. Any servers managed by config management or within
an enterprise should never be auto-rebooted and probably should not
notify anyone other than the monitoring system, via reboot-required.

So there probably needs to be a debconf prompt for this.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


signature.asc
Description: This is a digitally signed message part

Re: unattended-upgrades by default?

[Adrian Bunk]

On Tue, Nov 08, 2016 at 11:16:53AM +0800, Paul Wise wrote:
> On Tue, Nov 8, 2016 at 4:26 AM, Adam Borowski wrote:
> 
> > Forced reboot on upgrade is damage.  Let's learn from errors of others.
> 
> needrestart has a mechanism (needrestart-session) to hook into user
> sessions, perhaps that could be extended to request users reboot for
> security updates.

But that does not help here.

Steve was saying:
  that's not so useful on a remote server installation where
  there's no desktop for the system to show a pop-up or similar.
and
  We're *definitely* going to do it for cloud images

Any "solution" for the reboot problem that assumes that there is a user 
who regularly logs into the machine misses the problem.

> bye,
> pabs

cu
Adrian

-- 

   "Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
   "Only a promise," Lao Er said.
   Pearl S. Buck - Dragon Seed

Re: unattended-upgrades by default?

[Paul Wise]

On Tue, Nov 8, 2016 at 4:26 AM, Adam Borowski wrote:

> Forced reboot on upgrade is damage.  Let's learn from errors of others.

needrestart has a mechanism (needrestart-session) to hook into user
sessions, perhaps that could be extended to request users reboot for
security updates.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Re: unattended-upgrades by default?

[Moritz Mühlenhoff]

Steve McIntyre  schrieb:
> Definitely. I think we've got general consenus here, and we should do
> the following:
>
>  * work on fixing some of the highlighted bugs in unattended-upgrades
>
>  * enable it for installation via d-i by default. At installation
>time, it should be enabled by default with a clear message to the
>user saying so and giving them the choice to disable if preferred.
>
>  * document these changes, and give clear guidance for people on what
>to do about it if they want to disable u-u.
>
> Who's in for helping with this, please?

If you're going that route, you need to make sure to clearly indicate
that people still need subscribe to debian-security-announce. We will
inevitably have cases where additionally information is needed to
set an update into effect.

Cheers,
Moritz

Re: unattended-upgrades by default?

[Bernd Zeimetz]

On 11/04/2016 12:33 AM, Martin Zobel-Helas wrote:
> One side mark: once we start that, we might expose users to the public
> that they run this, as then a lot of users will send a similar sized
> packets to the internet! But i see no real security concern with that.

where is the difference between users running apt-get regularly and
unattended-upgrades doing so? I'd expect that the cronjob runs on a
random time anyway.


-- 
 Bernd ZeimetzDebian GNU/Linux Developer
 http://bzed.dehttp://www.debian.org
 GPG Fingerprint: ECA1 E3F2 8E11 2432 D485  DD95 EB36 171A 6FF9 435F

Re: unattended-upgrades by default?

[Adam Borowski]

On Fri, Nov 04, 2016 at 10:51:15PM +0200, Adrian Bunk wrote:
> On Thu, Nov 03, 2016 at 06:47:28PM +, Steve McIntyre wrote:
> >...
> >  * it will be a different experience compared to what people will get
> >when installing Debian normally, using d-i / debootstrap. Most
> >(all?) of our desktop environments already have some automatic
> >notification of available updates, but (a) not everybody uses them;
> >and (b) that's not so useful on a remote server installation where
> >there's no desktop for the system to show a pop-up or similar.
> >...
> 
> Should Debian also default to automatically reboot?

Based on what Windows admins and users say, it would be a terrible decision,
leading to unexpected data loss, when your computer reboots while you have
unsaved state.  And you can't say "reboot when no one is logged on" as GUI
users don't log out anymore.

Restarting a single daemon is in a vast majority of cases safe.  It might
harm a fallover scheme, and certain clients (for example, SQL ones -- a
non-buggy one must be always prepared to restart a transaction, but losing
a temporary table might be unexpected); for most, though, a momentary loss
of service is transparent to users.  Kernel reboots, not so.

> If the answer is "no", then nothing is a solution that does not also 
> solve how to notify the user when a new security update of the kernel 
> was automatically installed on his remote server.

Servers are expected to have a MTA or a monitoring system for that.  For GUI
systems there are new-fangled notifications because someone had a problem
with good old "You have new mail." upon opening a terminal (and some new
users, ignoring all that is holy, might even not open that terminal at all,
bastards!), but _some_ form of notification is expected.

Forced reboot on upgrade is damage.  Let's learn from errors of others.


Meow!
-- 
A MAP07 (Dead Simple) raspberry tincture recipe: 0.5l 95% alcohol, 1kg
raspberries, 0.4kg sugar; put into a big jar for 1 month.  Filter out and
throw away the fruits (can dump them into a cake, etc), let the drink age
at least 3-6 months.

Re: unattended-upgrades by default?

[Felipe Sateler]

On Mon, 07 Nov 2016 16:15:34 +0100, Michael Biebl wrote:

> Am 07.11.2016 um 15:55 schrieb Felipe Sateler:
>> On Mon, 07 Nov 2016 15:07:50 +0100, Michael Biebl wrote:
>> 
>> 
>>> See
>>> https://blogs.gnome.org/lkundrak/2015/08/27/networkmanager-1-0-6-
brings-
>> metered-connections-api-and-more/
>>>
>>> This can be set explicitly by the user, e.g. for a WiFi connection.
>> 
>> Where is the setting? I can't find it in the NM applet, and a comment
>> on that link indicates there was no GUI at the time. Has this been
>> added since?
> 
> nmcli -f connection.metered connection show 
> 
> I don't think there is a GUI for setting that option. Use nmcli
> connection modify  connection.metered 

Thanks. It would be nice to have this in the GUI as well (and ponies 
too ;).

> 
> (fwiw, nmcli has nice tab completion)

It appears the zsh completion is lagging behind.



-- 
Saludos,
Felipe Sateler

Re: unattended-upgrades by default?

[Steve McIntyre]

Lars Wirzenius wrote:
>On Thu, Nov 03, 2016 at 06:47:28PM +, Steve McIntyre wrote:
>> One of the topics that we've been talking about yesterday is automatic
>> software upgrades of cloud images. Some of the cloud platform
>> providers really want this so that unsophisticated / inexperienced
>> users of Debian images on their platforms will be secure by
>> default. But there are potential issues here:
>
>I am in favour of enabling automatic updates, particularly security
>updates, on clould images by default. In fact, I wouldn't mind having
>them on all types of installation by default. In my opinion, the
>ecosystem-wide security benefits of having Debian systems keep up to
>date with security updates by default overweigh any inconvenience of
>having to tweak system configuration on hosts where the automatic
>updates are problematic.
>
>If we do this, we should prominently note it in release notes and have
>a (wiki) page that explains how to turn off the automatic updates.

Definitely. I think we've got general consenus here, and we should do
the following:

 * work on fixing some of the highlighted bugs in unattended-upgrades

 * enable it for installation via d-i by default. At installation
   time, it should be enabled by default with a clear message to the
   user saying so and giving them the choice to disable if preferred.

 * document these changes, and give clear guidance for people on what
   to do about it if they want to disable u-u.

Who's in for helping with this, please?

-- 
Steve McIntyre, Cambridge, UK.st...@einval.com
  Armed with "Valor": "Centurion" represents quality of Discipline,
  Honor, Integrity and Loyalty. Now you don't have to be a Caesar to
  concord the digital world while feeling safe and proud.

Re: unattended-upgrades by default?

[Steve McIntyre]

Michael Biebl wrote:
>
>NetworkManager (since 1.0.6) exposes the information whether a
>connection is metered.
>
>See
>https://blogs.gnome.org/lkundrak/2015/08/27/networkmanager-1-0-6-brings-metered-connections-api-and-more/
>
>This can be set explicitly by the user, e.g. for a WiFi connection.
>
>Maybe u-a could query that information?
>
>That said, I read Steve's proposal to install u-a only for cloud-images.

We're *definitely* going to do it for cloud images, but (maybe this
wasn't 100% clear) I'm proposing we do it by default via d-i too. One
of the things that we're keen on for the cloud images is minimising
the user-visible changes compared to what happens in a "standard"
Debian system.

-- 
Steve McIntyre, Cambridge, UK.st...@einval.com
  Armed with "Valor": "Centurion" represents quality of Discipline,
  Honor, Integrity and Loyalty. Now you don't have to be a Caesar to
  concord the digital world while feeling safe and proud.

Re: unattended-upgrades by default?

[Michael Biebl]

Am 07.11.2016 um 15:55 schrieb Felipe Sateler:
> On Mon, 07 Nov 2016 15:07:50 +0100, Michael Biebl wrote:
> 

>> See
>> https://blogs.gnome.org/lkundrak/2015/08/27/networkmanager-1-0-6-brings-
> metered-connections-api-and-more/
>>
>> This can be set explicitly by the user, e.g. for a WiFi connection.
> 
> Where is the setting? I can't find it in the NM applet, and a comment on 
> that link indicates there was no GUI at the time. Has this been added 
> since?

nmcli -f connection.metered connection show 

I don't think there is a GUI for setting that option. Use
nmcli connection modify  connection.metered 

(fwiw, nmcli has nice tab completion)

-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature

Re: unattended-upgrades by default?

[Felipe Sateler]

On Mon, 07 Nov 2016 15:07:50 +0100, Michael Biebl wrote:

> Am 07.11.2016 um 14:48 schrieb Felipe Sateler:
>> On Thu, 03 Nov 2016 18:47:28 +, Steve McIntyre wrote:
>> 
>>> To solve the issue and provide security updates by default, I'm
>>> proposing that we should switch to installing unattended-upgrades by
>>> default (and enabling it too) *unless* something else in the
>>> installation is already expected to deal with security updates.
>>>
>>> Thoughts?
>> 
>> Is there a way to mark network connections as "expensive", and thus u-a
>> does nothing if only connected via that?
>> 
>> It would be very annoying to have packages automatically downloaded
>> when tethering my phone connection.
> 
> NetworkManager (since 1.0.6) exposes the information whether a
> connection is metered.

Oh this is nice. That post also suggests packagekit uses that too so it 
should not download stuff over metered connection.

> 
> See
> https://blogs.gnome.org/lkundrak/2015/08/27/networkmanager-1-0-6-brings-
metered-connections-api-and-more/
> 
> This can be set explicitly by the user, e.g. for a WiFi connection.

Where is the setting? I can't find it in the NM applet, and a comment on 
that link indicates there was no GUI at the time. Has this been added 
since?

> 
> Maybe u-a could query that information?

That would help a lot on systems that use networkmanager, which would be 
the majority of laptops. Although probably most of those already have 
packagekit that notifies when upgrades are available, so the need is less.

> 
> That said, I read Steve's proposal to install u-a only for cloud-images.

Yes, for cloud images it most likely is not a problem.

-- 
Saludos,
Felipe Sateler

Re: unattended-upgrades by default?

[Michael Biebl]

Am 07.11.2016 um 14:48 schrieb Felipe Sateler:
> On Thu, 03 Nov 2016 18:47:28 +, Steve McIntyre wrote:
> 
>> To solve the issue and provide security updates by default, I'm
>> proposing that we should switch to installing unattended-upgrades by
>> default (and enabling it too) *unless* something else in the
>> installation is already expected to deal with security updates.
>>
>> Thoughts?
> 
> Is there a way to mark network connections as "expensive", and thus u-a 
> does nothing if only connected via that?
> 
> It would be very annoying to have packages automatically downloaded when 
> tethering my phone connection.

NetworkManager (since 1.0.6) exposes the information whether a
connection is metered.

See
https://blogs.gnome.org/lkundrak/2015/08/27/networkmanager-1-0-6-brings-metered-connections-api-and-more/

This can be set explicitly by the user, e.g. for a WiFi connection.

Maybe u-a could query that information?

That said, I read Steve's proposal to install u-a only for cloud-images.

Michael

-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature

Re: unattended-upgrades by default?

[W. Martin Borgert]

Quoting Felipe Sateler :

Is there a way to mark network connections as "expensive", and thus u-a
does nothing if only connected via that?

It would be very annoying to have packages automatically downloaded when
tethering my phone connection.


Good point!

Even Wifi might be cheap or expensive, depending on the situation.
At home or in the office it might be an almost unlimited resource,
but if one is in a hotel or elsewhere one might have traffic limits
based on MAC or room number.
An upgrade might prevent users from being able to read their email
afterwards.

Re: unattended-upgrades by default?

[Felipe Sateler]

On Thu, 03 Nov 2016 18:47:28 +, Steve McIntyre wrote:

> To solve the issue and provide security updates by default, I'm
> proposing that we should switch to installing unattended-upgrades by
> default (and enabling it too) *unless* something else in the
> installation is already expected to deal with security updates.
> 
> Thoughts?

Is there a way to mark network connections as "expensive", and thus u-a 
does nothing if only connected via that?

It would be very annoying to have packages automatically downloaded when 
tethering my phone connection.

-- 
Saludos,
Felipe Sateler

Re: unattended-upgrades by default?

[Guido Günther]

On Fri, Nov 04, 2016 at 02:56:59PM +0100, Jonas Smedegaard wrote:
> Quoting Guido Günther (2016-11-04 12:26:51)
> > We should also enable needsrestart, whatmaps, checkrestart or similar 
> > to restart affected services after these upgrades otherwise the e.g. 
> > openssl update might go without effect until openssh, bind, 
> >  get restarted manually or rebooted.
> 
> needrestart (notice: only one "s") works out of the box, hooking into 
> APT by scanning after each APT run and emitting warnings both in APT 
> session and (with needrestart-session installed) in X11 user session.

I meant needrestart and looks like the most featurefull of the three.

> 
> checkrestart is in package debian-goodies.  I don't use it but believe 
> it is not integrated with default APT package handling workflow.
> 
> I was unaware of whatmaps.  Thanks for promoting that, Guido.  Seems 
> from its package description that it doesn't integrate with APT out of 
> the box either - is that correct?

It integrates with apt by creating a interim restart script which is
then run automatically after the upgrade via DPkg::Pre-Install-Pkgs and
DPkg::Post-Invoke.

Cheers,
 -- Guido

Re: unattended-upgrades by default?

[Paul Wise]

On Sat, Nov 5, 2016 at 1:25 PM, Michael Vogt wrote:

> Thanks for this reminder Paul! #828215 is fixed in git and will be
> part of the next upload (which should happy early next week).

Thanks! If you have time, a fix for jessie/wheezy would be appreciated too.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Re: unattended-upgrades by default?

[gustavo panizzo (gfa)]

On Thu, Nov 03, 2016 at 06:47:28PM +, Steve McIntyre wrote:
> Hey folks,
> 
> I'm in Seattle for the Debian Cloud sprint and it's going really
> well. I'll post a report in a few days summarising what we've
> done. But, in the meantime, there's something that has come up which I
> think merits wider discussion.

I work on a large managed hosting provider, our images, vm and dedicated
servers have unattended-updates or yum-cron by default.

Some customers choose to disable it, when a cluster is built it is disabled as 
well,
but a large percentage of our customers (>90%) have auto updates running every 
night.
Kernel updates are disabled, mostly to avoid filing up /boot on old servers,
and because we don't reboot automatically.

I'm not going to say it never failed but the failure ratio is very
very small


-- 
1AE0 322E B8F7 4717 BDEA BF1D 44BB 1BA7 9F6C 6333

keybase: https://keybase.io/gfa

Re: unattended-upgrades by default?

[Michael Vogt]

On Fri, Nov 04, 2016 at 02:36:27PM +0100, Alexandre Detiste wrote:
> 2016-11-04 13:29 GMT+01:00 Roland Mas :
> > Tangentially related: is there something similar for kernels?  My
> > monitoring setup currently compares the age of the most recent file in
> > /boot with the uptime, but I feel there must be something more proper
> > somewhere.
> 
> Unattended-Upgrades can also handle this by itself, it ships a
>  /etc/kernel/postinst.d/unattended-upgrades
> hook that create a
>  /var/run/reboot-required trigger;
> which tell UU to reboot the computer
> after updates includiong a kernel are done. (1)
> 
> This was a bit harsh to reboot with people logged now,
> so now UU can also check for active users. (2)
> 
> (1) & (2) are disabled by default; there's also
> "Unattended-Upgrade::Automatic-Reboot-Time",
> for school & offices.

It might be worth pointing out that the /var/run/reboot-required is
always created even if u-u- is configured to not act on it. So a
monitoring system and watch for this file and we may consider showing
on login (e.g. via motd) that the system needs a restart if this file
is present.

Cheers,
 Michael

Re: unattended-upgrades by default?

[Michael Vogt]

On Fri, Nov 04, 2016 at 03:38:38PM +0800, Paul Wise wrote:
> On Fri, Nov 4, 2016 at 2:47 AM, Steve McIntyre wrote:
[..]
> > To solve the issue and provide security updates by default, I'm
> > proposing that we should switch to installing unattended-upgrades by
> > default (and enabling it too) *unless* something else in the
> > installation is already expected to deal with security updates.
> 
> I think that would be acceptable once the fix for #828215 is uploaded.
> Until then, enabling unattended-upgrades is a minor but guaranteed
> data loss: upgraded automatically installed packages are set to
> manually installed.

Thanks for this reminder Paul! #828215 is fixed in git and will be
part of the next upload (which should happy early next week).

Cheers,
 Michael

Re: unattended-upgrades by default?

[Adrian Bunk]

On Fri, Nov 04, 2016 at 10:27:00PM +, Holger Levsen wrote:
> On Fri, Nov 04, 2016 at 10:51:15PM +0200, Adrian Bunk wrote:
> > Should Debian also default to automatically reboot?
> > 
> > If the answer is "no", then nothing is a solution that does not also 
> > solve how to notify the user when a new security update of the kernel 
> > was automatically installed on his remote server.
>  
> while you are 100% right, this is also a clear case of "perfect is the
> enemy of very good" ;-)

Steve suggested a solution that would avoid the problem of sending 
notifications.

But his solution cannot work properly without notifications.

It is very valuable that Steve started the discussion,
but his suggested solution might not be the best one.

Is "unattended-upgrades by default" actually a "very good" solution?
What would be alternatives?
Does "default" mean that this would happen without asking the user?
What are other distributions (not only Ubuntu) doing?

The Debian Cloud sprint is the background of this discussion.
What tools do people use to setup Debian cloud servers?
What options do these give to query the user during installation?
What notification options are available for these servers?
What UIs will the "inexperienced users" use to setup and manage
their servers?

unattended-upgrades (or something similar) will likely be part of any 
good solution. But everyone should be aware that it is not a complete
solution, and it is worth to start by also searching for better solutions.

> cheers,
>   Holger

cu
Adrian

-- 

   "Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
   "Only a promise," Lao Er said.
   Pearl S. Buck - Dragon Seed

Re: unattended-upgrades by default?

[Josh Triplett]

Rhonda D'Vine wrote:
> * Steve McIntyre  [2016-11-03 19:47:28 CET]:
> > One of the topics that we've been talking about yesterday is automatic
> > software upgrades of cloud images. Some of the cloud platform
> > providers really want this so that unsophisticated / inexperienced
> > users of Debian images on their platforms will be secure by
> > default. But there are potential issues here:
> > 
> >  * if users are providing a service like a database from a cloud
> >instance, there may be unexpected (potentially lengthy) downtime if
> >upgrades happen. Of course, this can be mitigated by disabling the
> >upgrade job on those machines if desired but that needs people to
> >know to do this. Experienced users will probably be dealing with
> >upgrades already, so this should not be an issue.
> 
>  It's not only databases.  It's also caching services like varnish, or
> cluster software which would trigger a failover then.
> 
>  In theory I'm all for it, but there definitely should be some more fine
> tuning for that.  Please don't auto-restart varnish by needrestart, it
> puts a lot of load on the backend which might be a very bad idea.  And
> the downtime that a mysql upgrade brings along is kinda annoying.

I absolutely agree that you usually can't restart services automatically
on production servers, and you have to coordinate with the admin to
choose an appropriate time.

However, I'd also suggest that more services and service management
tools need mechanisms for zero-downtime upgrades.  For instance, with
some care, services running via socket activation can restart without
losing any connections.

- Josh Triplett

Re: unattended-upgrades by default?

[Holger Levsen]

On Fri, Nov 04, 2016 at 10:51:15PM +0200, Adrian Bunk wrote:
> Should Debian also default to automatically reboot?
> 
> If the answer is "no", then nothing is a solution that does not also 
> solve how to notify the user when a new security update of the kernel 
> was automatically installed on his remote server.
 
while you are 100% right, this is also a clear case of "perfect is the
enemy of very good" ;-)


-- 
cheers,
Holger


signature.asc
Description: Digital signature

Re: unattended-upgrades by default?

[Adrian Bunk]

On Thu, Nov 03, 2016 at 06:47:28PM +, Steve McIntyre wrote:
>...
>  * it will be a different experience compared to what people will get
>when installing Debian normally, using d-i / debootstrap. Most
>(all?) of our desktop environments already have some automatic
>notification of available updates, but (a) not everybody uses them;
>and (b) that's not so useful on a remote server installation where
>there's no desktop for the system to show a pop-up or similar.
>...

Should Debian also default to automatically reboot?

If the answer is "no", then nothing is a solution that does not also 
solve how to notify the user when a new security update of the kernel 
was automatically installed on his remote server.

cu
Adrian

-- 

   "Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
   "Only a promise," Lao Er said.
   Pearl S. Buck - Dragon Seed

Re: unattended-upgrades by default?

[Noah Meyerhans]

On Fri, Nov 04, 2016 at 04:15:58PM +0100, Rhonda D'Vine wrote:
>  In theory I'm all for it, but there definitely should be some more fine
> tuning for that.  Please don't auto-restart varnish by needrestart, it
> puts a lot of load on the backend which might be a very bad idea.  And
> the downtime that a mysql upgrade brings along is kinda annoying.
> 
>  And: cluster setups might be a real pain here.  If you restart the
> cluster software at the same time you potentially run into split brain
> issues.
> 
>  So: BIG yeah for single-user non-critical systems, big nay and
> headaches for production nodes. 

Any reasonably well managed production host is going to be driven by
some kind of configuration management system and the admin can override
the default. They'll undoubtedly be overriding several defaults already.

Overriding the default (or simply purging unattended-upgrades) is a
trivial step in such an environment. And if for some reason it's not
trivial, then I think this is another case for wanting the service
enabled by default.

noah



signature.asc
Description: PGP signature

Re: unattended-upgrades by default?

[Sandro Tosi]

On Fri, Nov 4, 2016 at 9:13 AM, Luca Capello  wrote:
>
> I still think that a non-manual upgrade (i.e. an upgrade which has not
> been checked by a manual process, which means that a scripted upgrade is
> not part of it) should not be a default on any OS, but it seems I am the
> only one thinking like this...

we are at least in 2! while i may or may not care if there is an
obscure security fix in a perl module and that it's upgraded
automatically, i am pretty sure that on the machines i administer
professionally i never ever ever want to have mysql (to name one)
upgraded automatically.

I can see the benefit on a desktop machine, so as long as there is an
easy/non-cumbersome way to opt machines out of the autothing i have no
problem with it.

-- 
Sandro "morph" Tosi
My website: http://sandrotosi.me/
Me at Debian: http://wiki.debian.org/SandroTosi
G+: https://plus.google.com/u/0/+SandroTosi

Re: unattended-upgrades by default?

[Rhonda D'Vine]

 Hi!

* Steve McIntyre  [2016-11-03 19:47:28 CET]:
> One of the topics that we've been talking about yesterday is automatic
> software upgrades of cloud images. Some of the cloud platform
> providers really want this so that unsophisticated / inexperienced
> users of Debian images on their platforms will be secure by
> default. But there are potential issues here:
> 
>  * if users are providing a service like a database from a cloud
>instance, there may be unexpected (potentially lengthy) downtime if
>upgrades happen. Of course, this can be mitigated by disabling the
>upgrade job on those machines if desired but that needs people to
>know to do this. Experienced users will probably be dealing with
>upgrades already, so this should not be an issue.

 It's not only databases.  It's also caching services like varnish, or
cluster software which would trigger a failover then.

 In theory I'm all for it, but there definitely should be some more fine
tuning for that.  Please don't auto-restart varnish by needrestart, it
puts a lot of load on the backend which might be a very bad idea.  And
the downtime that a mysql upgrade brings along is kinda annoying.

 And: cluster setups might be a real pain here.  If you restart the
cluster software at the same time you potentially run into split brain
issues.

 So: BIG yeah for single-user non-critical systems, big nay and
headaches for production nodes. 

 Just my thoughts,
Rhonda
-- 
Fühlst du dich mutlos, fass endlich Mut, los  |
Fühlst du dich hilflos, geh raus und hilf, los| Wir sind Helden
Fühlst du dich machtlos, geh raus und mach, los   | 23.55: Alles auf Anfang
Fühlst du dich haltlos, such Halt und lass los|

Re: unattended-upgrades by default?

[Timo Juhani Lindfors]

Steve McIntyre <st...@einval.com> writes:
> To solve the issue and provide security updates by default, I'm
> proposing that we should switch to installing unattended-upgrades by
> default (and enabling it too) *unless* something else in the
> installation is already expected to deal with security updates.

Sounds like a good idea. At the minimum the image should ask (how?) the
user if they want to enable automatic updates. I've seen many admins who
don't even know about the unattended-upgrades package so we should be
advertising it more.

On my virtual machines I usually configure automatic updates and
automatic reboot daily or weekly to ensure that I don't have any
run-time configuration that would be break after e.g. a power outage.

-Timo

Re: unattended-upgrades by default?

[Holger Levsen]

On Fri, Nov 04, 2016 at 02:13:35PM +0100, Luca Capello wrote:
> I still think that a non-manual upgrade (i.e. an upgrade which has not
> been checked by a manual process, which means that a scripted upgrade is
> not part of it) should not be a default on any OS, but it seems I am the
> only one thinking like this...

do you also think so for appliances, like lightbulbs or washing
machines? Telefones^wcomputers in billions peoples pockets? 


-- 
cheers,
Holger, tempted to add: "billions of docker images?" ;)


signature.asc
Description: Digital signature

Re: unattended-upgrades by default?

[Jonas Smedegaard]

Quoting Guido Günther (2016-11-04 12:26:51)
> We should also enable needsrestart, whatmaps, checkrestart or similar 
> to restart affected services after these upgrades otherwise the e.g. 
> openssl update might go without effect until openssh, bind, 
>  get restarted manually or rebooted.

needrestart (notice: only one "s") works out of the box, hooking into 
APT by scanning after each APT run and emitting warnings both in APT 
session and (with needrestart-session installed) in X11 user session.

checkrestart is in package debian-goodies.  I don't use it but believe 
it is not integrated with default APT package handling workflow.

I was unaware of whatmaps.  Thanks for promoting that, Guido.  Seems 
from its package description that it doesn't integrate with APT out of 
the box either - is that correct?

If noone shouts out correcting my vague assessment here, I suggest we go 
with needrestart!


 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private


signature.asc
Description: signature

Re: unattended-upgrades by default?

[Alexandre Detiste]

2016-11-04 13:29 GMT+01:00 Roland Mas :
> Tangentially related: is there something similar for kernels?  My
> monitoring setup currently compares the age of the most recent file in
> /boot with the uptime, but I feel there must be something more proper
> somewhere.

Unattended-Upgrades can also handle this by itself, it ships a
 /etc/kernel/postinst.d/unattended-upgrades
hook that create a
 /var/run/reboot-required trigger;
which tell UU to reboot the computer
after updates includiong a kernel are done. (1)

This was a bit harsh to reboot with people logged now,
so now UU can also check for active users. (2)

(1) & (2) are disabled by default; there's also
"Unattended-Upgrade::Automatic-Reboot-Time",
for school & offices.

Greets,

Alexandre

Re: unattended-upgrades by default?

[Luca Capello]

Hi there!,

On Fri, 04 Nov 2016 12:26:51 +0100, Guido Günther wrote:
> On Thu, Nov 03, 2016 at 06:47:28PM +, Steve McIntyre wrote:
> > To solve the issue and provide security updates by default, I'm
> > proposing that we should switch to installing unattended-upgrades by
> > default (and enabling it too) *unless* something else in the
> > installation is already expected to deal with security updates.
> 
> Please do.

I still think that a non-manual upgrade (i.e. an upgrade which has not
been checked by a manual process, which means that a scripted upgrade is
not part of it) should not be a default on any OS, but it seems I am the
only one thinking like this...

> We should also enable needsrestart, whatmaps, checkrestart or
> similar to restart affected services after these upgrades otherwise the
> e.g. openssl update might go without effect until openssh, bind,
>  get restarted manually or rebooted.

Should not we recycle how the debpkg:libc6 handles affected-debpkgs or,
better, should not we unify libc6 behavior with the tools Guido
suggested?

Thx, bye,
Gismo / Luca


signature.asc
Description: Digital signature

Re: unattended-upgrades by default?

[Samuel Thibault]

Roland Mas, on Fri 04 Nov 2016 13:29:02 +0100, wrote:
> Guido Günther, 2016-11-04 12:26:51 +0100 :
> > Please do. We should also enable needsrestart, whatmaps, checkrestart
> > or similar to restart affected services after these upgrades otherwise
> > the e.g. openssl update might go without effect until openssh, bind,
> >  get restarted manually or rebooted.
> 
> Tangentially related: is there something similar for kernels?

needrestart also checks the running kernel.

Samuel

Re: unattended-upgrades by default?

[Roland Mas]

Guido Günther, 2016-11-04 12:26:51 +0100 :

[...]

> Please do. We should also enable needsrestart, whatmaps, checkrestart
> or similar to restart affected services after these upgrades otherwise
> the e.g. openssl update might go without effect until openssh, bind,
>  get restarted manually or rebooted.

Tangentially related: is there something similar for kernels?  My
monitoring setup currently compares the age of the most recent file in
/boot with the uptime, but I feel there must be something more proper
somewhere.

Roland.
-- 
Roland Mas

Indépendant en informatique libre -- Free software freelance
http://www.gnurandal.com/

Re: unattended-upgrades by default?

[Guido Günther]

On Thu, Nov 03, 2016 at 06:47:28PM +, Steve McIntyre wrote:
> Hey folks,
> 
> I'm in Seattle for the Debian Cloud sprint and it's going really
> well. I'll post a report in a few days summarising what we've
> done. But, in the meantime, there's something that has come up which I
> think merits wider discussion.
> 
> One of the topics that we've been talking about yesterday is automatic
> software upgrades of cloud images. Some of the cloud platform
> providers really want this so that unsophisticated / inexperienced
> users of Debian images on their platforms will be secure by
> default. But there are potential issues here:
> 
>  * if users are providing a service like a database from a cloud
>instance, there may be unexpected (potentially lengthy) downtime if
>upgrades happen. Of course, this can be mitigated by disabling the
>upgrade job on those machines if desired but that needs people to
>know to do this. Experienced users will probably be dealing with
>upgrades already, so this should not be an issue.
> 
>  * it will be a different experience compared to what people will get
>when installing Debian normally, using d-i / debootstrap. Most
>(all?) of our desktop environments already have some automatic
>notification of available updates, but (a) not everybody uses them;
>and (b) that's not so useful on a remote server installation where
>there's no desktop for the system to show a pop-up or similar.
> 
> To solve the issue and provide security updates by default, I'm
> proposing that we should switch to installing unattended-upgrades by
> default (and enabling it too) *unless* something else in the
> installation is already expected to deal with security updates.

Please do. We should also enable needsrestart, whatmaps, checkrestart or
similar to restart affected services after these upgrades otherwise the
e.g. openssl update might go without effect until openssh, bind,
 get restarted manually or rebooted.

Cheers,
 -- Guido

Re: unattended-upgrades by default?

[Paul Wise]

On Fri, Nov 4, 2016 at 2:47 AM, Steve McIntyre wrote:

>  * it will be a different experience compared to what people will get
>when installing Debian normally, using d-i / debootstrap.

That should be fixed in d-i IMO.

> To solve the issue and provide security updates by default, I'm
> proposing that we should switch to installing unattended-upgrades by
> default (and enabling it too) *unless* something else in the
> installation is already expected to deal with security updates.

I think that would be acceptable once the fix for #828215 is uploaded.
Until then, enabling unattended-upgrades is a minor but guaranteed
data loss: upgraded automatically installed packages are set to
manually installed.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Re: unattended-upgrades by default?

[Martin Zobel-Helas]

Hi, 

On Thu Nov 03, 2016 at 18:47:28 +, Steve McIntyre wrote:
> Hey folks,
> 
> I'm in Seattle for the Debian Cloud sprint and it's going really
> well. I'll post a report in a few days summarising what we've
> done. But, in the meantime, there's something that has come up which I
> think merits wider discussion.
> 
> One of the topics that we've been talking about yesterday is automatic
> software upgrades of cloud images. Some of the cloud platform
> providers really want this so that unsophisticated / inexperienced
> users of Debian images on their platforms will be secure by
> default. But there are potential issues here:
> 
>  * if users are providing a service like a database from a cloud
>instance, there may be unexpected (potentially lengthy) downtime if
>upgrades happen. Of course, this can be mitigated by disabling the
>upgrade job on those machines if desired but that needs people to
>know to do this. Experienced users will probably be dealing with
>upgrades already, so this should not be an issue.
> 
>  * it will be a different experience compared to what people will get
>when installing Debian normally, using d-i / debootstrap. Most
>(all?) of our desktop environments already have some automatic
>notification of available updates, but (a) not everybody uses them;
>and (b) that's not so useful on a remote server installation where
>there's no desktop for the system to show a pop-up or similar.
> 
> To solve the issue and provide security updates by default, I'm
> proposing that we should switch to installing unattended-upgrades by
> default (and enabling it too) *unless* something else in the
> installation is already expected to deal with security updates.
> 
> Thoughts?

+1! 

One side mark: once we start that, we might expose users to the public
that they run this, as then a lot of users will send a similar sized
packets to the internet! But i see no real security concern with that.

Cheers,
Martin
-- 
 Martin Zobel-Helas <zo...@debian.org>Debian System Administrator
 Debian & GNU/Linux Developer   Debian Listmaster
 http://about.me/zobel   Debian Webmaster
 GPG Fingerprint:  6B18 5642 8E41 EC89 3D5D  BDBB 53B1 AC6D B11B 627B 

Re: unattended-upgrades by default?

[Stefano Zacchiroli]

On Thu, Nov 03, 2016 at 06:47:28PM +, Steve McIntyre wrote:
> To solve the issue and provide security updates by default, I'm
> proposing that we should switch to installing unattended-upgrades by
> default (and enabling it too)

Please do. I've been doing this for ages on all my Debian machines, and
never regretted it.

Yes, in some cases you do not want unattended-upgrades for reasons like
those you mentioned, but those are the special cases, not the default.
We should just prominently document the change, so that users that need
to avoid unattended-upgrades know how to do so.

Thanks for bringing up this topic,
Cheers.
-- 
Stefano Zacchiroli . z...@upsilon.cc . upsilon.cc/zack . . o . . . o . o
Computer Science Professor . CTO Software Heritage . . . . . o . . . o o
Former Debian Project Leader . OSI Board Director  . . . o o o . . . o .
« the first rule of tautology club is the first rule of tautology club »

Re: unattended-upgrades by default?

[Russell Stuart]

On Thu, 2016-11-03 at 18:47 +, Steve McIntyre wrote:
> To solve the issue and provide security updates by default, I'm
> proposing that we should switch to installing unattended-upgrades by
> default (and enabling it too) *unless* something else in the
> installation is already expected to deal with security updates.

I am amazed we don't do this already.  Effectively it makes us insecure
by default.

signature.asc
Description: This is a digitally signed message part

Re: unattended-upgrades by default?

[Lars Wirzenius]

On Thu, Nov 03, 2016 at 06:47:28PM +, Steve McIntyre wrote:
> One of the topics that we've been talking about yesterday is automatic
> software upgrades of cloud images. Some of the cloud platform
> providers really want this so that unsophisticated / inexperienced
> users of Debian images on their platforms will be secure by
> default. But there are potential issues here:

I am in favour of enabling automatic updates, particularly security
updates, on clould images by default. In fact, I wouldn't mind having
them on all types of installation by default. In my opinion, the
ecosystem-wide security benefits of having Debian systems keep up to
date with security updates by default overweigh any inconvenience of
having to tweak system configuration on hosts where the automatic
updates are problematic.

If we do this, we should prominently note it in release notes and have
a (wiki) page that explains how to turn off the automatic updates.

-- 
I want to build worthwhile things that might last. --joeyh


signature.asc
Description: PGP signature

Re: unattended-upgrades by default?

[Mathieu Parent (Debian)]

2016-11-03 19:47 GMT+01:00 Steve McIntyre <st...@einval.com>:
> Hey folks,

Hello,

[...]
> To solve the issue and provide security updates by default, I'm
> proposing that we should switch to installing unattended-upgrades by
> default (and enabling it too) *unless* something else in the
> installation is already expected to deal with security updates.
>
> Thoughts?

+1.

Ubuntu does a similar thing. See
https://patches.ubuntu.com/p/pkgsel/pkgsel_0.43ubuntu2.patch for how
(but does pkgsel applies to cloud image creation?).

Regards
-- 
Mathieu Parent

unattended-upgrades by default?

[Steve McIntyre]

Hey folks,

I'm in Seattle for the Debian Cloud sprint and it's going really
well. I'll post a report in a few days summarising what we've
done. But, in the meantime, there's something that has come up which I
think merits wider discussion.

One of the topics that we've been talking about yesterday is automatic
software upgrades of cloud images. Some of the cloud platform
providers really want this so that unsophisticated / inexperienced
users of Debian images on their platforms will be secure by
default. But there are potential issues here:

 * if users are providing a service like a database from a cloud
   instance, there may be unexpected (potentially lengthy) downtime if
   upgrades happen. Of course, this can be mitigated by disabling the
   upgrade job on those machines if desired but that needs people to
   know to do this. Experienced users will probably be dealing with
   upgrades already, so this should not be an issue.

 * it will be a different experience compared to what people will get
   when installing Debian normally, using d-i / debootstrap. Most
   (all?) of our desktop environments already have some automatic
   notification of available updates, but (a) not everybody uses them;
   and (b) that's not so useful on a remote server installation where
   there's no desktop for the system to show a pop-up or similar.

To solve the issue and provide security updates by default, I'm
proposing that we should switch to installing unattended-upgrades by
default (and enabling it too) *unless* something else in the
installation is already expected to deal with security updates.

Thoughts?

-- 
Steve McIntyre, Cambridge, UK.st...@einval.com
"I suspect most samba developers are already technically insane... Of
 course, since many of them are Australians, you can't tell." -- Linus Torvalds