Re: Unattended Upgrades Ran Anyway.

[Max Nikulin]

On 11/12/2023 06:12, Charles Curley wrote:


Sorry. I had already stopped the apt-daily-upgrade.timer, which
triggers the unattended upgrade service. (The couldn't give them
similar names to act as a mnemonic?) This refers to disabling the
unattended upgrade service.


I have not tested it, but from unit and scripts content my impression is 
that apt-daily-upgrade.service may apply security updates even when the 
unattended-upgrades package is not installed. Despite 
apt-daily-upgrade.timer is enabled out of the box, without 
unattended-upgrades, the service does nothing in default configuration. 
There are apt.conf settings to enable/diable upgrades.


As to "systemctl mask UNIT.service", the valid use case is suppressing a 
service that may be activated through D-Bus. The price is noise in logs 
on each attempt to invoke a D-Bus method. I am unsure if D-Bus specs 
allows to hide a D-Bus .service file (do not confuse with systemd 
services) installed by some package.


Usually it is enough to "systemdctl disable --now UNIT" for a .timer or 
a .socket that may cause activation of the service.


I assume unit dependencies and preventing accidental start from command 
line are rather specific use cases.

Re: Unattended Upgrades Ran Anyway.

[songbird]

Dan Ritter wrote:
> Stefan Monnier wrote: 
>> On my trusty Thinkpad X30, upgrades are sufficiently taxing that having
>> them run unexpectedly can be a real problem, so I tried to prevent
>> unattended upgrades a few months ago.
>
>
> I have always preferred the apticron package, which by default
> updates daily and sends an email letting me know that they are
> available, rather than doing the upgrade itself.

  as everyone can have their own reasons for what they are
doing i would not expect anyone else to do what i am but
since we're on the topic.  :)

  i do not run auto updates of any kind for Debian (for
either testing or stable or any other instances i may
have set up).  currently i don't have any oddities out
there running.  instead, each morning i cold start my
computer (i prefer it being off when i am not using it)
and it boots into testing i drag in my new e-mails and
usenet group posts and then fire up the update of the
indexes for the various Debian package repositories it
needs.  after the update finishes then i check to see
what kind of updates are there.  some days i scan the
list and just pull it all and apply them, other days i
will hold certain packages because i don't want to deal
with it that day.  i run a few packages from sid/unstable
but they usually are self-contained enough that i don't
worry about it.


  songbird

Re: Unattended Upgrades Ran Anyway.

[Charles Curley]

On Sun, 10 Dec 2023 17:27:39 -0500
Greg Wooledge  wrote:

> > 
> > Thanks. I will disable as well.  
> 
> Disable *what*?  Disabling a .service unit which is triggered by a
> timer event isn't going to stop it from running.

Sorry. I had already stopped the apt-daily-upgrade.timer, which
triggers the unattended upgrade service. (The couldn't give them
similar names to act as a mnemonic?) This refers to disabling the
unattended upgrade service.

> 
> *Masking* a .service would prevent it from running when requested by a
> timer event.
> 
> Apart from that, you'd have to remove the timer event.  However you do
> that.  I've never used systemd timers yet.

I *think* that's got it. Now to be sure I remember all this when it
comes time to allow automatic upgrades again.

-- 
Does anybody read signatures any more?

https://charlescurley.com
https://charlescurley.com/blog/

Re: Unattended Upgrades Ran Anyway.

[Greg Wooledge]

On Sun, Dec 10, 2023 at 02:10:43PM -0700, Charles Curley wrote:
> On Sun, 10 Dec 2023 14:51:48 -0600
> David Wright  wrote:
> 
> > I think it might be worth googling and reading "three levels of off"
> > (with the quotes).
> > 
> >   1. You can stop a service. That simply terminates the running
> >  instance of the service and does little else. If due to some form
> >  of activation (such as manual activation, socket activation, bus
> >  activation, activation by system boot or activation by hardware
> >  plug) the service is requested again afterwards it will be
> >  started. Stopping a service is hence a very simple, temporary and
> >  superficial operation.
> 
> Thanks. I will disable as well.

Disable *what*?  Disabling a .service unit which is triggered by a timer
event isn't going to stop it from running.

*Masking* a .service would prevent it from running when requested by a
timer event.

Apart from that, you'd have to remove the timer event.  However you do
that.  I've never used systemd timers yet.

Re: Unattended Upgrades Ran Anyway.

[Charles Curley]

On Sun, 10 Dec 2023 14:51:48 -0600
David Wright  wrote:

> I think it might be worth googling and reading "three levels of off"
> (with the quotes).
> 
>   1. You can stop a service. That simply terminates the running
>  instance of the service and does little else. If due to some form
>  of activation (such as manual activation, socket activation, bus
>  activation, activation by system boot or activation by hardware
>  plug) the service is requested again afterwards it will be
>  started. Stopping a service is hence a very simple, temporary and
>  superficial operation.

Thanks. I will disable as well.

-- 
Does anybody read signatures any more?

https://charlescurley.com
https://charlescurley.com/blog/

Re: Unattended Upgrades Ran Anyway.

[Dan Ritter]

Stefan Monnier wrote: 
> On my trusty Thinkpad X30, upgrades are sufficiently taxing that having
> them run unexpectedly can be a real problem, so I tried to prevent
> unattended upgrades a few months ago.


I have always preferred the apticron package, which by default
updates daily and sends an email letting me know that they are
available, rather than doing the upgrade itself.

-dsr-

Re: Unattended Upgrades Ran Anyway.

[David Wright]

On Sun 10 Dec 2023 at 13:39:50 (-0700), Charles Curley wrote:
> On Sun, 10 Dec 2023 14:17:36 -0600
> David Wright  wrote:
> 
> > Why is the service loaded, enabled and enabled then? Don't you need
> > to disable or mask it? Presumably it sits there, dead, all day
> > normally, and pops up at an appropriate time.
> 
> As I understand things, start and stop are for immediate changes.
> enable and disable are for boot time. So the service is turned off
> until I either start it up again manually or reboot the computer.
> 
> Then there's masking, which is a whole nother can of lawyers. And a
> slew of other states. See Table 1.  is-enabled output, in man systemctl.

I think it might be worth googling and reading "three levels of off"
(with the quotes).

  1. You can stop a service. That simply terminates the running
 instance of the service and does little else. If due to some form
 of activation (such as manual activation, socket activation, bus
 activation, activation by system boot or activation by hardware
 plug) the service is requested again afterwards it will be
 started. Stopping a service is hence a very simple, temporary and
 superficial operation.

Cheers,
David.

Re: Unattended Upgrades Ran Anyway.

[Charles Curley]

On Sun, 10 Dec 2023 14:17:36 -0600
David Wright  wrote:

> Why is the service loaded, enabled and enabled then? Don't you need
> to disable or mask it? Presumably it sits there, dead, all day
> normally, and pops up at an appropriate time.

As I understand things, start and stop are for immediate changes.
enable and disable are for boot time. So the service is turned off
until I either start it up again manually or reboot the computer.

Then there's masking, which is a whole nother can of lawyers. And a
slew of other states. See Table 1.  is-enabled output, in man systemctl.

-- 
Does anybody read signatures any more?

https://charlescurley.com
https://charlescurley.com/blog/

Re: Unattended Upgrades Ran Anyway.

[David Wright]

On Sun 10 Dec 2023 at 11:00:37 (-0700), Charles Curley wrote:
> On Sun, 10 Dec 2023 16:11:44 +
> Michael Kjörling <2695bd53d...@ewoof.net> wrote:
> 
> > On 10 Dec 2023 08:49 -0700, from charlescur...@charlescurley.com
> > (Charles Curley): [...]  
> > 
> > Exactly how did you "shut down" unattended-upgrades?
> > 
> 
> root@chaffee:/etc/dhcp# systemctl stop unattended-upgrades.service 
> root@chaffee:/etc/dhcp# systemctl status unattended-upgrades.service 
> ● unattended-upgrades.service - Unattended Upgrades Shutdown
>  Loaded: loaded (/lib/systemd/system/unattended-upgrades.service; 
> enabled; vendor preset: enabled)
>  Active: inactive (dead) since Sat 2023-12-09 19:06:51 MST; 6s ago
>Docs: man:unattended-upgrade(8)
> Process: 540 
> ExecStart=/usr/share/unattended-upgrades/unattended-upgrade-shutdown 
> --wait-for-signal (code=exited, status=0/SUCCESS)
>Main PID: 540 (code=exited, status=0/SUCCESS)
> CPU: 1.661s
> 
> Oct 09 02:02:20 chaffee systemd[1]: Started Unattended Upgrades Shutdown.
> Dec 09 19:06:42 chaffee systemd[1]: Stopping Unattended Upgrades Shutdown...
> Dec 09 19:06:51 chaffee systemd[1]: unattended-upgrades.service: Succeeded.
> Dec 09 19:06:51 chaffee systemd[1]: Stopped Unattended Upgrades Shutdown.
> Dec 09 19:06:51 chaffee systemd[1]: unattended-upgrades.service: Consumed 
> 1.661s CPU time.
> root@chaffee:/etc/dhcp#

Why is the service loaded, enabled and enabled then? Don't you need
to disable or mask it? Presumably it sits there, dead, all day
normally, and pops up at an appropriate time.

Cheers,
David.

Re: Unattended Upgrades Ran Anyway.

[Charles Curley]

On Sun, 10 Dec 2023 23:59:04 +0700
Max Nikulin  wrote:

> On 10/12/2023 22:49, Charles Curley wrote:
>  [...]  
> 
> systemctl status apt-daily-upgrade.timer
> 

root@issola:~# systemctl status apt-daily-upgrade.timer
● apt-daily-upgrade.timer - Daily apt upgrade and clean activities
 Loaded: loaded (/etc/systemd/system/apt-daily-upgrade.timer; enabled; 
preset: enabled)
 Active: active (waiting) since Tue 2023-12-05 15:02:47 MST; 4 days ago
Trigger: Mon 2023-12-11 04:52:42 MST; 17h left
   Triggers: ● apt-daily-upgrade.service

Dec 05 15:02:47 issola systemd[1]: Started apt-daily-upgrade.timer - Daily apt 
upgrade and clean activities.
root@issola:~# 

Thank you.

-- 
Does anybody read signatures any more?

https://charlescurley.com
https://charlescurley.com/blog/

Re: Unattended Upgrades Ran Anyway.

[Charles Curley]

On Sun, 10 Dec 2023 16:11:44 +
Michael Kjörling <2695bd53d...@ewoof.net> wrote:

> On 10 Dec 2023 08:49 -0700, from charlescur...@charlescurley.com
> (Charles Curley): [...]  
> 
> Exactly how did you "shut down" unattended-upgrades?
> 

root@chaffee:/etc/dhcp# systemctl stop unattended-upgrades.service 
root@chaffee:/etc/dhcp# systemctl status unattended-upgrades.service 
● unattended-upgrades.service - Unattended Upgrades Shutdown
 Loaded: loaded (/lib/systemd/system/unattended-upgrades.service; enabled; 
vendor preset: enabled)
 Active: inactive (dead) since Sat 2023-12-09 19:06:51 MST; 6s ago
   Docs: man:unattended-upgrade(8)
Process: 540 
ExecStart=/usr/share/unattended-upgrades/unattended-upgrade-shutdown 
--wait-for-signal (code=exited, status=0/SUCCESS)
   Main PID: 540 (code=exited, status=0/SUCCESS)
CPU: 1.661s

Oct 09 02:02:20 chaffee systemd[1]: Started Unattended Upgrades Shutdown.
Dec 09 19:06:42 chaffee systemd[1]: Stopping Unattended Upgrades Shutdown...
Dec 09 19:06:51 chaffee systemd[1]: unattended-upgrades.service: Succeeded.
Dec 09 19:06:51 chaffee systemd[1]: Stopped Unattended Upgrades Shutdown.
Dec 09 19:06:51 chaffee systemd[1]: unattended-upgrades.service: Consumed 
1.661s CPU time.
root@chaffee:/etc/dhcp# 


-- 
Does anybody read signatures any more?

https://charlescurley.com
https://charlescurley.com/blog/

Re: Unattended Upgrades Ran Anyway.

[Stefan Monnier]

> I double checked this morning.  All machines had unattended upgrades
> shut off as of yesterday evening, well before the
> unattended-uogrades ran.

On my trusty Thinkpad X30, upgrades are sufficiently taxing that having
them run unexpectedly can be a real problem, so I tried to prevent
unattended upgrades a few months ago.

IIRC my first step was to remove the `unattended-upgrades` (which I had
manually installed many years ago, when I *did* want upgrades to be
automatic), but that did very little.

FWIW, it felt like "whack-a-mole", where there seemed to always be
another way unattended upgrades could be started :-(


Stefan

Re: Unattended Upgrades Ran Anyway.

[Max Nikulin]

On 10/12/2023 22:49, Charles Curley wrote:

root@issola:/var# systemctl status unattended-upgrades.service


systemctl status apt-daily-upgrade.timer

Re: Unattended Upgrades Ran Anyway.

[Michael Kjörling]

On 10 Dec 2023 08:49 -0700, from charlescur...@charlescurley.com (Charles 
Curley):
> Due to the recent traffic about the defective kernel in Bookworm
> (12.3), I shut down unattended-upgrades on all my machines (Bookworm
> and Bullseye). To my surprise, three of them ran unattended-upgrades
> anyway.

Exactly how did you "shut down" unattended-upgrades?

-- 
Michael Kjörling  https://michael.kjorling.se
“Remember when, on the Internet, nobody cared that you were a dog?”

Unattended Upgrades Ran Anyway.

[Charles Curley]

Due to the recent traffic about the defective kernel in Bookworm
(12.3), I shut down unattended-upgrades on all my machines (Bookworm
and Bullseye). To my surprise, three of them ran unattended-upgrades
anyway.

One of them is Bullseye, so it was a harmless error. But still….

The two Bookworm machines are recent installations, to 12.2 as
upgraded. Fortunately, in both cases the upgrade failed because someone
was smart enough to pull the plug on the defective kernel. My thanks to
that someone.

I double checked this morning. All machines had unattended upgrades
shut off as of yesterday evening, well before the unattended-uogrades
ran.

--
Date: Sun, 10 Dec 2023 04:43:10 -0700 (MST)
From: root@issola.localdomain
To: charles@issola.localdomain
Subject: unattended-upgrades result for issola.localdomain: FAILURE

Unattended upgrade result: The URI http://deb.debian.org/debian/pool/m
 ain/l/linux-signed-amd64/linux-image-6.1.0-14-amd64_6.1.64-1_amd64.de
 b failed to download, aborting

Unattended-upgrades log:
Starting unattended upgrades script
Allowed origins are: origin=Debian,codename=bookworm-updates, 
origin=Debian,codename=bookworm,label=Debian,
+origin=Debian,codename=bookworm,label=Debian-Security, 
origin=Debian,codename=bookworm-security,label=Debian-Security
Initial blacklist:
Initial whitelist (not strict):
An error occurred: 403  Access denied - broken package [IP: 192.168.100.12 3142]
The URI 
http://deb.debian.org/debian/pool/main/l/linux-signed-amd64/linux-image-6.1.0-14-amd64_6.1.64-1_amd64.deb
 failed to download,
+aborting
--
root@issola:/var# systemctl status unattended-upgrades.service 
○ unattended-upgrades.service - Unattended Upgrades Shutdown
 Loaded: loaded (/lib/systemd/system/unattended-upgrades.service; enabled; 
preset: enabled)
 Active: inactive (dead) since Sat 2023-12-09 19:06:51 MST; 13h ago
   Duration: 4d 4h 4min 2.799s
   Docs: man:unattended-upgrade(8)
Process: 786 
ExecStart=/usr/share/unattended-upgrades/unattended-upgrade-shutdown 
--wait-for-signal (code=exited, status=0/SUCCESS)
   Main PID: 786 (code=exited, status=0/SUCCESS)
CPU: 87ms

Dec 05 15:02:48 issola systemd[1]: Started unattended-upgrades.service - 
Unattended Upgrades Shutdown.
Dec 09 19:06:51 issola systemd[1]: Stopping unattended-upgrades.service - 
Unattended Upgrades Shutdown...
Dec 09 19:06:51 issola systemd[1]: unattended-upgrades.service: Deactivated 
successfully.
Dec 09 19:06:51 issola systemd[1]: Stopped unattended-upgrades.service - 
Unattended Upgrades Shutdown.
[1]+  Donefirewall-config
root@issola:/var# 

-- 
Does anybody read signatures any more?

https://charlescurley.com
https://charlescurley.com/blog/

Re: Report a bug against which package - unattended-upgrades / apt / dpkg ??

[Dan Ritter]

David Wright wrote: 
> On Mon 21 Mar 2022 at 15:07:45 (+), Dr. Alex Sheppard wrote:
> > On 21/03/2022 14:02, Dan Ritter wrote:
> > > Dr. Alex Sheppard wrote:
> > So, unless anyone can explain otherwise, I think there is a bug to
> > report against unattended-upgrades.
> 
> Perhaps. But I'd avoid the risks in autoremoving anything. In fact,
> I only automate the _downloading_ of upgradeable candidates.

That's how I do it for my household systems. At work, we
maintain mirrors and local repos and rank our systems so that a
problematic package change should show up first in a manual
test, then in a limited pool of machines, and hopefully never in
the production pools.

-dsr-

Re: Report a bug against which package - unattended-upgrades / apt / dpkg ??

[David Wright]

On Mon 21 Mar 2022 at 15:07:45 (+), Dr. Alex Sheppard wrote:
> On 21/03/2022 14:02, Dan Ritter wrote:
> > Dr. Alex Sheppard wrote:
> > > 
> > >      Unattended upgrades ended up removing some of the packages it was was
> > > going to upgrade ... bind9 being one of them and thereby breaking DNS on a
> > > client's network.
> > > 
> > >      Is this a bug in unattended upgrades, or a bug in apt or dpkg? Here 
> > > is
> > > an extract from my unattended-upgrades.log to illustrate.

It might help to check other logs like dpkg.log¹, apt/history.log², and
auth.log³, and also the contents of /var/cache/apt/archives/{,partial/}⁴
to try to find out why bind9 wasn't upgraded. Was it even downloaded?
BTW does unattended upgrades send failure reports to /var/mail/sysadmin?

> > >      FTR: I'm struggling to think how bind9 could have been installed as a
> > > dependency for something else on the machine in question. I am pretty 
> > > sure I
> > > would have installed it manually which gives extra surprise to it being
> > > autoremoved.

Do you have backups of previous versions of /var/lib/apt/extended_states
which might give evidence of that. Otherwise, confirming a bug
might be difficult.

> > unattended-upgrades should not be allowed to autoremove. Doing
> > so always ends up with surprises, unless you have pre-tested
> > everything and keep your own apt repo a day or two behind
> > Debian's.
> > 
> > Unattended-Upgrade::Remove-Unused-Dependencies "false";
> > Unattended-Upgrade::Remove-New-Unused-Dependencies "false";

> My config had the normal "like apt-get autoremove" disabled as per default
> """
> // Do automatic removal of unused packages after the upgrade
> // (equivalent to apt-get autoremove)
> // Unattended-Upgrade::Remove-Unused-Dependencies "false";
> """
> 
> Whereas removing newly unused packages was enabled  - also as per the
> default
> """
> // Do automatic removal of newly unused dependencies after the upgrade
> // Unattended-Upgrade::Remove-New-Unused-Dependencies "true";
> """
> 
> My issue arose not from doing "the equivalent to apt-get autoremove"
> but by whatever "Remove-New-Unused-Dependencies" does. Does anybody
> know how the logic of this works / what commands are run to achieve
> this?

The logic would appear to be that Remove-Unused-Dependencies="true"
would effectively run an autoremove at some time in the process.
Assume package M0 depends on D0, and D0 was auto-installed. And say
that yesterday you removed M0, but ignored the fact that D0 could now
be autoremoved. You might expect that an unattended-upgrade would
remove D0 on account of Remove-Unused-Dependencies="true".

However, Remove-New-Unused-Dependencies="true" should leave D0 alone.

OTOH if a package M1 (having a dependency D1) was upgraded to a more
well-endowed version that dispensed with the services of D1, then
D1 now has the status of a newly unused dependency, and so
Remove-New-Unused-Dependencies="true" will autoremove it.

> The way I see it there is a bug in either:
> 
>     a) The logic in unattended-upgrades of how it goes about
> fulfilling "Remove-New-Unused-Dependencies"
> 
>         or
> 
>     b) An underlying command that is called to fulfill the
> "Remove-New-Unused-Dependencies" operation
> 
>         or
> 
>     c) Uninstalling a package that it just upgraded seems like a
> mistake that ought to be catchable, but if there is just no way to do
> the "Remove-New-Unused-Dependencies" operation without risk of
> something important getting [un]installed, the bug is that this is enabled
> by default.

I don't see why it is necessarily a mistake. In the example above,
there might be a package P1 that other people use, and which needs
D1 to be upgraded. It would then come down to a matter of the relative
timing of the decision to upgrade D1 and the decision to autoremove
it. I would say that the autoremove decision can only be taken /after/
the success (or failure) of all the upgrades involved.

> So, unless anyone can explain otherwise, I think there is a bug to
> report against unattended-upgrades.

Perhaps. But I'd avoid the risks in autoremoving anything. In fact,
I only automate the _downloading_ of upgradeable candidates.

¹ Did bind9 get upgraded at all?
² Did it intend to upgrade all the upgradeables?
³ Was the correct number of packages downloaded from debian-security?
⁴ Unfortunately, any recent apt-cleaning will prevent you knowing
  whether bind9…10u7 ever arrived on the system.

Cheers,
David.

Re: Report a bug against which package - unattended-upgrades / apt / dpkg ??

[Dr. Alex Sheppard]

On 21/03/2022 14:02, Dan Ritter wrote:

Dr. Alex Sheppard wrote:

Hi,

     Unattended upgrades ended up removing some of the packages it was was
going to upgrade ... bind9 being one of them and thereby breaking DNS on a
client's network.

     Is this a bug in unattended upgrades, or a bug in apt or dpkg? Here is
an extract from my unattended-upgrades.log to illustrate.

     FTR: I'm struggling to think how bind9 could have been installed as a
dependency for something else on the machine in question. I am pretty sure I
would have installed it manually which gives extra surprise to it being
autoremoved.

unattended-upgrades should not be allowed to autoremove. Doing
so always ends up with surprises, unless you have pre-tested
everything and keep your own apt repo a day or two behind
Debian's.

Unattended-Upgrade::Remove-Unused-Dependencies "false";
Unattended-Upgrade::Remove-New-Unused-Dependencies "false";

However,
Unattended-Upgrade::Remove-Unused-Kernel-Packages
is usually safe, unless you have very specific reasons to keep
multiple old kernels around.

-dsr-

Thanks Dan, I've updated my config accordingly to avoid this happening 
in future :-)


It's not so urgent for me now, but I still get the feeling there is a 
bug to report.



My config had the normal "like apt-get autoremove" disabled as per default
"""
// Do automatic removal of unused packages after the upgrade
// (equivalent to apt-get autoremove)
// Unattended-Upgrade::Remove-Unused-Dependencies "false";
"""

Whereas removing newly unused packages was enabled  - also as per the 
default

"""
// Do automatic removal of newly unused dependencies after the upgrade
// Unattended-Upgrade::Remove-New-Unused-Dependencies "true";
"""


My issue arose not from doing "the equivalent to apt-get autoremove" but 
by whatever "Remove-New-Unused-Dependencies" does. Does anybody know how 
the logic of this works / what commands are run to achieve this?


The way I see it there is a bug in either:

    a) The logic in unattended-upgrades of how it goes about fulfilling 
"Remove-New-Unused-Dependencies"


        or

    b) An underlying command that is called to fulfill the 
"Remove-New-Unused-Dependencies" operation


        or

    c) Uninstalling a package that it just upgraded seems like a 
mistake that ought to be catchable, but if there is just no way to do 
the "Remove-New-Unused-Dependencies" operation without risk of something 
important getting installed, the bug is that this is enabled by default.



So, unless anyone can explain otherwise, I think there is a bug to 
report against unattended-upgrades.















Dr. Alex Sheppard
http://www.das-computer.co.uk <http://das-computer.co.uk>

Re: Report a bug against which package - unattended-upgrades / apt / dpkg ??

[Dan Ritter]

Dr. Alex Sheppard wrote: 
> Hi,
> 
>     Unattended upgrades ended up removing some of the packages it was was
> going to upgrade ... bind9 being one of them and thereby breaking DNS on a
> client's network.
> 
>     Is this a bug in unattended upgrades, or a bug in apt or dpkg? Here is
> an extract from my unattended-upgrades.log to illustrate.
> 
>     FTR: I'm struggling to think how bind9 could have been installed as a
> dependency for something else on the machine in question. I am pretty sure I
> would have installed it manually which gives extra surprise to it being
> autoremoved.

unattended-upgrades should not be allowed to autoremove. Doing
so always ends up with surprises, unless you have pre-tested
everything and keep your own apt repo a day or two behind
Debian's.

Unattended-Upgrade::Remove-Unused-Dependencies "false";
Unattended-Upgrade::Remove-New-Unused-Dependencies "false";

However, 
Unattended-Upgrade::Remove-Unused-Kernel-Packages
is usually safe, unless you have very specific reasons to keep
multiple old kernels around.

-dsr-

Report a bug against which package - unattended-upgrades / apt / dpkg ??

[Dr. Alex Sheppard]

Hi,

    Unattended upgrades ended up removing some of the packages it was 
was going to upgrade ... bind9 being one of them and thereby breaking 
DNS on a client's network.


    Is this a bug in unattended upgrades, or a bug in apt or dpkg? Here 
is an extract from my unattended-upgrades.log to illustrate.


    FTR: I'm struggling to think how bind9 could have been installed as 
a dependency for something else on the machine in question. I am pretty 
sure I would have installed it manually which gives extra surprise to it 
being autoremoved.



"""
2022-03-19 00:50:02,051 INFO Checking if system is running on battery is 
skipped. Please install powermgmt-base package to check power status and 
skip installing updates when the system is running on battery.

2022-03-19 00:50:02,091 INFO Initial blacklist :
2022-03-19 00:50:02,092 INFO Initial whitelist:
2022-03-19 00:50:02,092 INFO Starting unattended upgrades script
2022-03-19 00:50:02,092 INFO Allowed origins are: 
origin=Debian,codename=buster,label=Debian, 
origin=Debian,codename=buster,label=Debian-Security
2022-03-19 06:26:44,369 INFO Checking if system is running on battery is 
skipped. Please install powermgmt-base package to check power status and 
skip installing updates when the system is running on battery.

2022-03-19 06:26:44,375 INFO Initial blacklist :
2022-03-19 06:26:44,375 INFO Initial whitelist:
2022-03-19 06:26:44,376 INFO Starting unattended upgrades script
2022-03-19 06:26:44,376 INFO Allowed origins are: 
origin=Debian,codename=buster,label=Debian, 
origin=Debian,codename=buster,label=Debian-Security
2022-03-19 06:26:48,609 INFO *Packages that will be upgraded: bind9 
bind9-host **bind9utils dnsutils* libbind9-161 libdns-export1104 
libdns1104 libirs-export161 libirs161 libisc-export1100 libisc1100 
libisccc161 libisccfg-export163 libisccfg163 liblwres161
2022-03-19 06:26:48,610 INFO Writing dpkg log to 
/var/log/unattended-upgrades/unattended-upgrades-dpkg.log
2022-03-19 06:26:49,218 WARNING Keeping auto-removable libirs161 
package(s) because it would also remove the following packages which 
should be kept in this step: bind9utils
2022-03-19 06:27:08,325 WARNING Keeping auto-removable liblwres161 
package(s) because it would also remove the following packages which 
should be kept in this step: bind9utils libbind9-161 libdns1104 
libisc1100 libisccc161 libisccfg163
2022-03-19 06:27:27,161 INFO *Packages that were successfully 
auto-removed:* avahi-daemon *bind9 bind9-host dnsutils host* 
libavahi-core7 libdaemon0 libnss-mdns
2022-03-19 06:27:27,161 INFO Packages that are kept back: libirs161 
liblwres161

"""

Thanks,

Alex


--
Dr. Alex Sheppard
http://www.das-computer.co.uk <http://das-computer.co.uk>

Re: consulta unattended-upgrades

[Toni Mas Soler]

Doncs per aportar punts de vista: sempre a mà i subscrit a llista de d'avisos 
de seguretat. 

La majora de vegades puc esperar a l'actualització periòdica setmana perquè el 
forat no m'aplica.

Context: Debian stable 

 - 99% corrent sense X, serveis propis i programes bàsics. 

 - Puntualment en "experiència usuari" amb les X les aplicacions habituals 
d'escriptori.


Toni Mas
GPG 3F42A21D84D7E950

Sent with ProtonMail Secure Email.

‐‐‐ Original Message ‐‐‐
En dimecres 2 de juny de 2021 a les 19:36, Eloi  va 
escriure:

> Explico la meva experiència posant tres exemples:
> 

> -   Ordinador de treball amb Debian testing: sempre actualitzat a mà. A
> més, com que testing no té suport per actualitzacions de seguretat, en
> aquest escenari unattended-upgrades faria més mal que bé.
> 

> -   Ordinador de treball amb Debian stable (familiar): unattended-upgrades
> configurat només per a les actualitzacions de seguretat. Només en casos
> molt específics un programa salta de versió (penso, per exemple, en el
> Mozilla Firefox), des de Debian sempre es té molta cura de traslladar
> només els pedaços que resolen els problemes de seguretat sense incloure
> altres canvis funcionals, i s'ha de reconèixer que ho fan molt molt bé.
> 

> -   Servidor en producció amb Debian stable: actualitzo a mà durant les
> finestres de manteniment per necessitats de servei. En aquest cas
> considero imprescindible estar subscrit a debian-security-announce per
> fer-ne una gestió adequada.
> 

> Per exemple, no fa ni mitja hora ha saltat avís a la llista
> d'actualització per a firefox-esr:
> 

> https://lists.debian.org/debian-security-announce/2021/msg00108.html
> 

> 

> Què faré jo?
> 

> -   Ordinador amb testing: tocarà actualitzar-lo
> -   Ordinador amb stable: ja s'actualitzarà
> -   Servidor amb stable: no té firefox instal·lat, ni em preocupo
> 

> Faig constar que aquest criteri només l'aplico a Debian, no a
> derivades com Ubuntu (que evito com la pesta).
> 

> YMMV.
>



signature.asc
Description: OpenPGP digital signature

Re: consulta unattended-upgrades

[Eloi]

Explico la meva experiència posant tres exemples:

* Ordinador de treball amb Debian testing: *sempre* actualitzat a mà. A 
més, com que testing no té suport per actualitzacions de seguretat, en 
aquest escenari unattended-upgrades faria més mal que bé.


* Ordinador de treball amb Debian stable (familiar): unattended-upgrades 
configurat només per a les actualitzacions de seguretat. Només en casos 
molt específics un programa salta de versió (penso, per exemple, en el 
Mozilla Firefox), des de Debian sempre es té molta cura de traslladar 
només els pedaços que resolen els problemes de seguretat sense incloure 
altres canvis funcionals, i s'ha de reconèixer que ho fan molt molt bé.


* Servidor en producció amb Debian stable: actualitzo a mà durant les 
finestres de manteniment per necessitats de servei. En aquest cas 
considero imprescindible estar subscrit a debian-security-announce per 
fer-ne una gestió adequada.


Per exemple, no fa ni mitja hora ha saltat avís a la llista 
d'actualització per a firefox-esr:


<https://lists.debian.org/debian-security-announce/2021/msg00108.html>

Què faré jo?

* Ordinador amb testing: tocarà actualitzar-lo

* Ordinador amb stable: ja s'actualitzarà

* Servidor amb stable: no té firefox instal·lat, ni em preocupo

Faig constar que aquest criteri *només* l'aplico a Debian, no a 
derivades com Ubuntu (que evito com la pesta).


YMMV.

Re: consulta unattended-upgrades

[Griera]

A dimecres 02 de juny 2021,  vàreu escriure:

> On Wed, Jun 02, 2021 at 07:36:31AM +, xavi wrote:
> > 
> > Però igual sóc jo que sóc un lamer impenitent i que no m'entero. Per això
> > voldria saber les vostres opinions, aviam què opineu :)
> 
> Crec que la clau radica en diferenciar si l'actualització és de
> seguretat o incorpora millores.

Bé, jo només ho tinc activat per les actualitzacions de seguretat. Les altres 
entenc que poden sé més complexes i les faig a ma.

> 
> Potser la recomanació de
> https://packages.debian.org/en/jessie/cron-apt seria la clau.
> 

Re: consulta unattended-upgrades

[Griera]

A dimecres 02 de juny 2021,  vàreu escriure:

> __
> I'm using this dedicated address because personal addresses aren't
> masked enough at this mail public archive. Public archive administrator
> should fix this against automated addresses collectors.
> El 2/6/21 a les 10:23, Griera ha escrit:
> > A dimecres 02 de juny 2021,  vàreu escriure:
> > 
> >> Hola,
> >>
> >> No sé si aquesta pregunta vorejaria l'offtopic, però per si de cas us la 
> >> faig. A la feina i fins i tot a casa, a totes les meves màquines debian 
> >> i ubuntu faig servir sempre unattended-upgrades. Particularment en 
> >> aquelles que tenen accés a l'exterior (servidors i tal). Per mi és una 
> >> eina d'actualització de seguretat ràpida i potent. Però estic llegint a 
> >> grups de Telegram, i en alguna opinió d'algun company, que 
> >> unattended-upgrades mai, que les actualitzacions a mà.
> >>
> >> No acabo d'entendre què tenen en contra, que no se'ls hi actualitzin 
> >> programes que tinguin extremadíssimament configurats a mà i que tinguin 
> >> por que una actualització els aixafi la configuració prèvia? o que fent 
> >> servir unattended-upgrades un podria arribar a confiar-se en excés i 
> >> prefereixen anar actualitzant a mà? (aquest últim argument per mi seria 
> >> del nivell com no voler fer servir el wifi perquè com que te'l poden 
> >> crackejar).
> >>
> >> Però igual sóc jo que sóc un lamer impenitent i que no m'entero. Per 
> >> això voldria saber les vostres opinions, aviam què opineu :)
> >>
> >> Records i gràcies per endavant.
> >>
> >> x.
> >>
> > 
> > Jo, usuari vulgar i de perfil molt baix, ho tinc activat en els diferents 
> > ordinadors. Per mi és un tema de seguretat que preval per sobre d'altres 
> > consideracions. No tenir instal·lades les actualitzacions de seguretat pot 
> > portar a ensurts. Fa unes setmanes vaig obrir i connectar a Internet un 
> > ordinador que feia uns anys que no obria (¿un? ¿dos? ¿tres?). Tenia 
> > instal·lat una versió del firefox vulnerable (no s'havia actualitzat) i em 
> > van pispar el fitxer amb totes les contrasenyes desades. Per sort, totes 
> > banals: no en deso cap crítica. Però l'ensurt no te'l treu ningú.
> > 
> > Records.
> > 
> 
> Compte perquè el concepte de seguretat també és aplicable a poder
> comptar amb l'ordinador quan el necessites.

Sí, tens tota a raó, Narcís. El dia que provoqui problemes, ho deixaré de fer 
servir. De moment, m'ha funcionat i hi tinc confiança . . . fins que la perdi.


> 
> 
> Narcis Garcia
> 

Re: consulta unattended-upgrades

[Alex Muntada]

Deia l'Àlex:

> La meva experiència és que unattended-upgrades funciona bé en
> Debian estables i Ubuntus LTS sobre les actualitzacions de
> seguretat.

La meva experiència també és aquesta, tot i que en alguns casos
he patit problemes amb Ubuntu perquè l'actualització de seguretat
també incorporava canvis no relacionats i que no eren compatibles
(els paquets en qüestió eren dels lxc). Hi ha més risc que passi
això com més vella sigui la LTS (que va ser el cas del problema
amb el lxc: van portar una versió corregida d'una LTS més nova
a una de més vella).

Suposo que de vegades no és trivial resoldre un problema de
seguretat en versions antigues i cal forçar un canvi més gran i
amb l'u-u no veus els avisos corresponents. Però em sembla
recordar que si instal·les apt-listchanges els avisos s'envien
també per correu a root. També cal tenir en compte que els que
fem paquets també ens equivoquem de vegades...

En qualsevol cas, la clau està en el número de servidors a
gestionar i de com de crític siguin els seus serveis. Si en tens
un número prou gran no pots fer les actualitzacions manualment de
cap de les maneres i has de buscar altres estratègies (només els
de seguretat, només alguns paquets, congelar versions, tenir
imatges pròpies i refer-les regularment, alertes dels paquets
disponibles, monitoritzar els serveis, tenir una bateria de tests
per assegurar que funcionen, etc.).

També val a dir que de vegades u-u no pot actualitzar algun
paquet pel motiu que sigui i cal fer-ho manualment. Quan això ha
passat m'ha funcionat molt bé utilitzar dsh per executar la
mateixa ordre a un grup de servidors. També recordo que m'havien
parlat molt bé del apt-dater, però no l'he provat.

> Jo també soc dels que m'agrada instal.lar a mà actualitzacions,
> però les meves circumstàcies són que a casa treballo amb Debian
> Testing, on un cop a l'any alguna actualització pot posar el meu
> sistema a fer una mica el ruc.

Jo treballo amb estable per l'escriptori i unstable per a fer els
paquets. En tots dos casos actualitzo a mà per estar al cas dels
canvis que es fan i per no perdre'm els detalls.

> Altres cops les circumstàcies han estat instal.lar un servei
> amb Debian estable a algún lloc on no el podria administrar,
> i allà no veig millor solució que emprar unattended-upgrades.

Als ordinadors que he configurat a d'altra gent també els poso
actualitzacions automàtiques i en la mitja dotzena de servidors
que administro tinc configurat els u-u de seguretat perquè no puc
dedicar el temps necessari per fer-ho manualment. En aquests
casos utilitzo eines com logwatch i apt-listchanges per estar al
cas del que va passant.

Al final es tracta de triar on hom vol invertir el seu temps.

Salut,
Alex

--
  ⢀⣴⠾⠻⢶⣦⠀
  ⣾⠁⢠⠒⠀⣿⡁   Alex Muntada 
  ⢿⡄⠘⠷⠚⠋   Debian Developer  log.alexm.org
  ⠈⠳⣄



signature.asc
Description: PGP signature

Re: consulta unattended-upgrades

[Àlex]

Bones Xavi

La meva experiència és que unattended-upgrades funciona bé en Debian
estables i Ubuntus LTS sobre les actualitzacions de seguretat.

Jo també soc dels que m'agrada instal.lar a mà actualitzacions, però les
meves circumstàcies són que a casa treballo amb Debian Testing, on un
cop a l'any alguna actualització pot posar el meu sistema a fer una mica
el ruc.

Altres cops les circumstàcies han estat instal.lar un servei amb Debian
estable a algún lloc on no el podria administrar, i allà no veig millor
solució que emprar unattended-upgrades.

Tot depen de les circumstàncies,

Salutacions


    Àlex


El 2/6/21 a les 9:36, xavi ha escrit:
> Hola,
>
> No sé si aquesta pregunta vorejaria l'offtopic, però per si de cas us
> la faig. A la feina i fins i tot a casa, a totes les meves màquines
> debian i ubuntu faig servir sempre unattended-upgrades. Particularment
> en aquelles que tenen accés a l'exterior (servidors i tal). Per mi és
> una eina d'actualització de seguretat ràpida i potent. Però estic
> llegint a grups de Telegram, i en alguna opinió d'algun company, que
> unattended-upgrades mai, que les actualitzacions a mà.
>
> No acabo d'entendre què tenen en contra, que no se'ls hi actualitzin
> programes que tinguin extremadíssimament configurats a mà i que
> tinguin por que una actualització els aixafi la configuració prèvia? o
> que fent servir unattended-upgrades un podria arribar a confiar-se en
> excés i prefereixen anar actualitzant a mà? (aquest últim argument per
> mi seria del nivell com no voler fer servir el wifi perquè com que
> te'l poden crackejar).
>
> Però igual sóc jo que sóc un lamer impenitent i que no m'entero. Per
> això voldria saber les vostres opinions, aviam què opineu :)
>
> Records i gràcies per endavant.
>
> x.

Re: consulta unattended-upgrades

[Adrià]

On Wed, Jun 02, 2021 at 07:36:31AM +, xavi wrote:
> 
> Però igual sóc jo que sóc un lamer impenitent i que no m'entero. Per això
> voldria saber les vostres opinions, aviam què opineu :)

Crec que la clau radica en diferenciar si l'actualització és de
seguretat o incorpora millores.

Potser la recomanació de
https://packages.debian.org/en/jessie/cron-apt seria la clau.

Re: consulta unattended-upgrades

[Narcis Garcia]

__
I'm using this dedicated address because personal addresses aren't
masked enough at this mail public archive. Public archive administrator
should fix this against automated addresses collectors.
El 2/6/21 a les 10:23, Griera ha escrit:
> A dimecres 02 de juny 2021,  vàreu escriure:
> 
>> Hola,
>>
>> No sé si aquesta pregunta vorejaria l'offtopic, però per si de cas us la 
>> faig. A la feina i fins i tot a casa, a totes les meves màquines debian 
>> i ubuntu faig servir sempre unattended-upgrades. Particularment en 
>> aquelles que tenen accés a l'exterior (servidors i tal). Per mi és una 
>> eina d'actualització de seguretat ràpida i potent. Però estic llegint a 
>> grups de Telegram, i en alguna opinió d'algun company, que 
>> unattended-upgrades mai, que les actualitzacions a mà.
>>
>> No acabo d'entendre què tenen en contra, que no se'ls hi actualitzin 
>> programes que tinguin extremadíssimament configurats a mà i que tinguin 
>> por que una actualització els aixafi la configuració prèvia? o que fent 
>> servir unattended-upgrades un podria arribar a confiar-se en excés i 
>> prefereixen anar actualitzant a mà? (aquest últim argument per mi seria 
>> del nivell com no voler fer servir el wifi perquè com que te'l poden 
>> crackejar).
>>
>> Però igual sóc jo que sóc un lamer impenitent i que no m'entero. Per 
>> això voldria saber les vostres opinions, aviam què opineu :)
>>
>> Records i gràcies per endavant.
>>
>> x.
>>
> 
> Jo, usuari vulgar i de perfil molt baix, ho tinc activat en els diferents 
> ordinadors. Per mi és un tema de seguretat que preval per sobre d'altres 
> consideracions. No tenir instal·lades les actualitzacions de seguretat pot 
> portar a ensurts. Fa unes setmanes vaig obrir i connectar a Internet un 
> ordinador que feia uns anys que no obria (¿un? ¿dos? ¿tres?). Tenia 
> instal·lat una versió del firefox vulnerable (no s'havia actualitzat) i em 
> van pispar el fitxer amb totes les contrasenyes desades. Per sort, totes 
> banals: no en deso cap crítica. Però l'ensurt no te'l treu ningú.
> 
> Records.
> 

Compte perquè el concepte de seguretat també és aplicable a poder
comptar amb l'ordinador quan el necessites.


Narcis Garcia

Re: consulta unattended-upgrades

[Narcis Garcia]

Subscric el què diu en Jordi 215639, i afegeixo que a les
actualitzacions automàtiques els veig dos altres inconvenients:

1. Si l'ordinador està en ús, durant les descàrregues pot haver un ús
inesperat de l'ample de banda i durant les instal·lacions un ús
inesperat de disc que pot molestar l'usuari que volia fer alguna cosa
amb prioritat en aquell moment.

2. Una actualització podria coincidir inesperadament amb una aturada
manual de l'ordinador o pitjor: Amb una interrupció elèctrica i que els
errors no es vegin fins que justament fa falta utilitzar l'ordinador.
És millor topar-se amb els problemes quan ja dedicaves el temps a
atendre les actualitzacions.


Narcis Garcia

__
I'm using this dedicated address because personal addresses aren't
masked enough at this mail public archive. Public archive administrator
should fix this against automated addresses collectors.
El 2/6/21 a les 10:04, Jordi ha escrit:
> El dc. 02 de 06 de 2021 a les 07:36 +, en/na xavi va escriure:
>> Hola,
>>
>> No sé si aquesta pregunta vorejaria l'offtopic, però per si de cas us
>> la 
>> faig. A la feina i fins i tot a casa, a totes les meves màquines
>> debian 
>> i ubuntu faig servir sempre unattended-upgrades. Particularment en 
>> aquelles que tenen accés a l'exterior (servidors i tal). Per mi és
>> una 
>> eina d'actualització de seguretat ràpida i potent. Però estic llegint
>> a 
>> grups de Telegram, i en alguna opinió d'algun company, que 
>> unattended-upgrades mai, que les actualitzacions a mà.
>>
>> No acabo d'entendre què tenen en contra, que no se'ls hi actualitzin 
>> programes que tinguin extremadíssimament configurats a mà i que
>> tinguin 
>> por que una actualització els aixafi la configuració prèvia? o que
>> fent 
>> servir unattended-upgrades un podria arribar a confiar-se en excés i 
>> prefereixen anar actualitzant a mà? (aquest últim argument per mi
>> seria 
>> del nivell com no voler fer servir el wifi perquè com que te'l poden 
>> crackejar).
>>
>> Però igual sóc jo que sóc un lamer impenitent i que no m'entero. Per 
>> això voldria saber les vostres opinions, aviam què opineu :)
>>
>> Records i gràcies per endavant.
>>
>> x.
>>
> La meva opinió: trobo que si les coses es fan massa automàticament, en
> perds una mica el control. Jo abans em trobava que algunes coses no
> funcionaven com ho havien fet fins cert moment i és perquè alguna cosa
> s'havia actualitzat i alguna petita cosa funcionava de forma diferent.
> Els programes tampoc han d'estar "extremadíssimament configurats"
> perquè quelcom paràmetre deixi de funcionar o hi hagi nous paràmetres
> que facin coses noves. I això sense parlar d'actualitzacions prou
> importants ... Per això soc partidari de que el sistema m'avisi si hi
> ha actualitzacions però soc jo qui decideix quan fer-les.
> 
> salutacions
> 
> Jordi.
> 

Re: consulta unattended-upgrades

[Griera]

A dimecres 02 de juny 2021,  vàreu escriure:

> Hola,
> 
> No sé si aquesta pregunta vorejaria l'offtopic, però per si de cas us la 
> faig. A la feina i fins i tot a casa, a totes les meves màquines debian 
> i ubuntu faig servir sempre unattended-upgrades. Particularment en 
> aquelles que tenen accés a l'exterior (servidors i tal). Per mi és una 
> eina d'actualització de seguretat ràpida i potent. Però estic llegint a 
> grups de Telegram, i en alguna opinió d'algun company, que 
> unattended-upgrades mai, que les actualitzacions a mà.
> 
> No acabo d'entendre què tenen en contra, que no se'ls hi actualitzin 
> programes que tinguin extremadíssimament configurats a mà i que tinguin 
> por que una actualització els aixafi la configuració prèvia? o que fent 
> servir unattended-upgrades un podria arribar a confiar-se en excés i 
> prefereixen anar actualitzant a mà? (aquest últim argument per mi seria 
> del nivell com no voler fer servir el wifi perquè com que te'l poden 
> crackejar).
> 
> Però igual sóc jo que sóc un lamer impenitent i que no m'entero. Per 
> això voldria saber les vostres opinions, aviam què opineu :)
> 
> Records i gràcies per endavant.
> 
> x.
> 

Jo, usuari vulgar i de perfil molt baix, ho tinc activat en els diferents 
ordinadors. Per mi és un tema de seguretat que preval per sobre d'altres 
consideracions. No tenir instal·lades les actualitzacions de seguretat pot 
portar a ensurts. Fa unes setmanes vaig obrir i connectar a Internet un 
ordinador que feia uns anys que no obria (¿un? ¿dos? ¿tres?). Tenia instal·lat 
una versió del firefox vulnerable (no s'havia actualitzat) i em van pispar el 
fitxer amb totes les contrasenyes desades. Per sort, totes banals: no en deso 
cap crítica. Però l'ensurt no te'l treu ningú.

Records.

Re: consulta unattended-upgrades

[Jordi]

El dc. 02 de 06 de 2021 a les 07:36 +, en/na xavi va escriure:
> Hola,
> 
> No sé si aquesta pregunta vorejaria l'offtopic, però per si de cas us
> la 
> faig. A la feina i fins i tot a casa, a totes les meves màquines
> debian 
> i ubuntu faig servir sempre unattended-upgrades. Particularment en 
> aquelles que tenen accés a l'exterior (servidors i tal). Per mi és
> una 
> eina d'actualització de seguretat ràpida i potent. Però estic llegint
> a 
> grups de Telegram, i en alguna opinió d'algun company, que 
> unattended-upgrades mai, que les actualitzacions a mà.
> 
> No acabo d'entendre què tenen en contra, que no se'ls hi actualitzin 
> programes que tinguin extremadíssimament configurats a mà i que
> tinguin 
> por que una actualització els aixafi la configuració prèvia? o que
> fent 
> servir unattended-upgrades un podria arribar a confiar-se en excés i 
> prefereixen anar actualitzant a mà? (aquest últim argument per mi
> seria 
> del nivell com no voler fer servir el wifi perquè com que te'l poden 
> crackejar).
> 
> Però igual sóc jo que sóc un lamer impenitent i que no m'entero. Per 
> això voldria saber les vostres opinions, aviam què opineu :)
> 
> Records i gràcies per endavant.
> 
> x.
> 
La meva opinió: trobo que si les coses es fan massa automàticament, en
perds una mica el control. Jo abans em trobava que algunes coses no
funcionaven com ho havien fet fins cert moment i és perquè alguna cosa
s'havia actualitzat i alguna petita cosa funcionava de forma diferent.
Els programes tampoc han d'estar "extremadíssimament configurats"
perquè quelcom paràmetre deixi de funcionar o hi hagi nous paràmetres
que facin coses noves. I això sense parlar d'actualitzacions prou
importants ... Per això soc partidari de que el sistema m'avisi si hi
ha actualitzacions però soc jo qui decideix quan fer-les.

salutacions

Jordi.

consulta unattended-upgrades

[xavi]

Hola,

No sé si aquesta pregunta vorejaria l'offtopic, però per si de cas us la 
faig. A la feina i fins i tot a casa, a totes les meves màquines debian 
i ubuntu faig servir sempre unattended-upgrades. Particularment en 
aquelles que tenen accés a l'exterior (servidors i tal). Per mi és una 
eina d'actualització de seguretat ràpida i potent. Però estic llegint a 
grups de Telegram, i en alguna opinió d'algun company, que 
unattended-upgrades mai, que les actualitzacions a mà.


No acabo d'entendre què tenen en contra, que no se'ls hi actualitzin 
programes que tinguin extremadíssimament configurats a mà i que tinguin 
por que una actualització els aixafi la configuració prèvia? o que fent 
servir unattended-upgrades un podria arribar a confiar-se en excés i 
prefereixen anar actualitzant a mà? (aquest últim argument per mi seria 
del nivell com no voler fer servir el wifi perquè com que te'l poden 
crackejar).


Però igual sóc jo que sóc un lamer impenitent i que no m'entero. Per 
això voldria saber les vostres opinions, aviam què opineu :)


Records i gràcies per endavant.

x.

Re: Graphical session does not close until unattended-upgrades has applied all updates

[Yvan Masson]

Le 23/04/2021 à 21:07, Yvan Masson a écrit :

Le 23/04/2021 à 20:18, didier gaumet a écrit :


1) Unattended-upgrade at shutdown and after Lightdm is stopped: Perhaps 



a solution would be to :
- stop and disable the unattended-upgrade systemd service
- edit the unattended-upgrades config file to setup the shutdown to false
- write/enable/start your custom systemd service that runs 
/usr/bin/unattented-upgrade only after shutdown has been asked and the 



lightdm systemd service has been stopped


It might work, but I have doubt about my ability to do this properly to 


get reliable updates… I am sure this has already worked for me (in 
previous Debian or Ubuntu, can't remember), certainly with a very 
similar configuration. I have just compared the contents of the package 


from Ubuntu but could not find any notable difference. I will submit a 
bug report so that appropriate people are aware of this.


Done here: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=987431




2) unattended-upgrades notifications while Plymouth is running: I do 
not read Python but trying to understand this python script, I have 
the impression that Plymouth does notify the user that 
unattended-upgrédes is running


You are right, I should have clarify this in my previous answer: I have 


already seen this working (as I said i can't remember if it was in a 
previous Debian or Ubuntu).



Good luck ;-)


Thanks!





OpenPGP_signature
Description: OpenPGP digital signature

Re: Graphical session does not close until unattended-upgrades has applied all updates

[Yvan Masson]

Le 23/04/2021 à 20:18, didier gaumet a écrit :


1) Unattended-upgrade at shutdown and after Lightdm is stopped: Perhaps 



a solution would be to :
- stop and disable the unattended-upgrade systemd service
- edit the unattended-upgrades config file to setup the shutdown to false
- write/enable/start your custom systemd service that runs 
/usr/bin/unattented-upgrade only after shutdown has been asked and the 
lightdm systemd service has been stopped


It might work, but I have doubt about my ability to do this properly to 
get reliable updates… I am sure this has already worked for me (in 
previous Debian or Ubuntu, can't remember), certainly with a very 
similar configuration. I have just compared the contents of the package 
from Ubuntu but could not find any notable difference. I will submit a 
bug report so that appropriate people are aware of this.




2) unattended-upgrades notifications while Plymouth is running: I do not 
read Python but trying to understand this python script, I have the 
impression that Plymouth does notify the user that unattended-upgrédes 
is running


You are right, I should have clarify this in my previous answer: I have 
already seen this working (as I said i can't remember if it was in a 
previous Debian or Ubuntu).



Good luck ;-)


Thanks!



OpenPGP_signature
Description: OpenPGP digital signature

Re: Graphical session does not close until unattended-upgrades has applied all updates

[didier gaumet]

1) Unattended-upgrade at shutdown and after Lightdm is stopped: Perhaps 
a solution would be to :

- stop and disable the unattended-upgrade systemd service
- edit the unattended-upgrades config file to setup the shutdown to false
- write/enable/start your custom systemd service that runs 
/usr/bin/unattented-upgrade only after shutdown has been asked and the 
lightdm systemd service has been stopped


2) unattended-upgrades notifications while Plymouth is running: I do not 
read Python but trying to understand this python script, I have the 
impression that Plymouth does notify the user that unattended-upgrédes 
is running


Good luck ;-)

Re: Graphical session does not close until unattended-upgrades has applied all updates

[Yvan Masson]

Le 23/04/2021 à 12:14, didier gaumet a écrit :

Le 23/04/2021 à 11:59, didier gaumet a écrit :

I should check what I wrote before posting :-(

[...]

Disclaimer: I have never experimented myself whait I suggest


"what"

[...]
As for Plymouth notifying about ugrades during shutdown, if it is not 
already the case (when unattended-upgrades the 


A bit is missing there (cut/past and absent-minded poster): ..." systemd 
service is started after the LightDM systemd service is stopped), it is 



perhaps possible to modify the "...

unattended-upgrades.service systemd service to script Plymouth, or 
more simply, setup Plymouth to be more informative

http://blog.fpmurphy.com/2009/09/project-plymouth.html


Thanks Didier for your answer, it looked promising. Unfortunately I 
suppose it is not the way to go: unattended-upgrades.service starts 
`/usr/share/unattended-upgrades/unattended-upgrade-shutdown` at boot, 
which waits for "a signal". (I suppose from reading the code that it 
listen on dbus something related to systemd-logind, but my skills 
prevent me from going further). Anyway, in my case it starts properly, 
but it just prevents the session/LightDM from stopping. If no other 
idea, I suppose I should submit a bug report?


Regards,
Yvan



OpenPGP_signature
Description: OpenPGP digital signature

Re: Graphical session does not close until unattended-upgrades has applied all updates

[didier gaumet]

Le 23/04/2021 à 11:59, didier gaumet a écrit :

I should check what I wrote before posting :-(

[...]

Disclaimer: I have never experimented myself whait I suggest


"what"

[...]
As for Plymouth notifying about ugrades during shutdown, if it is not 
already the case (when unattended-upgrades the 


A bit is missing there (cut/past and absent-minded poster): ..." systemd 
service is started after the LightDM systemd service is stopped), it is 
perhaps possible to modify the "...


unattended-upgrades.service systemd service to script Plymouth, or more 
simply, setup Plymouth to be more informative

http://blog.fpmurphy.com/2009/09/project-plymouth.html

Re: Graphical session does not close until unattended-upgrades has applied all updates

[didier gaumet]

Le 23/04/2021 à 09:48, Yvan Masson a écrit :
[...]
I would expect the session to be completely closed, LightDM stopped, and 
the console or Plymouth displaying a message indicating the ongoing 
updates.

[...]

Hello,

Disclaimer: I have never experimented myself whait I suggest

Perhaps adapting the unattended-upgrades.service systemd service by 
declaring that the lightdm service is to be stopped before this service 
is started would do.


As for Plymouth notifying about ugrades during shutdown, if it is not 
already the case (when unattended-upgrades the 
unattended-upgrades.service systemd service to script Plymouth, or more 
simply, setup Plymouth to be more informative

http://blog.fpmurphy.com/2009/09/project-plymouth.html

Graphical session does not close until unattended-upgrades has applied all updates

[Yvan Masson]

Hi list,

I am preparing some Debian 11 desktops for a school (for when it will be 
the new stable). The setup is very simple: no root account, one 
partition, tasks desktop/Cinnamon/SSH. Unattended-upgrades is configured 
to install updates on shutdown (see 1): upgrading works properly, but is 
very disturbing for the users:


When the user chooses to shutdown or reboot the computer from his 
Cinnamon session, the session does not close until all updates are 
applied. While waiting:

- icons on the desktop disappear
- the usual menu that allows choosing between 
suspend/hibernate/reboot/cancel/shutdown won't appear again (see 2)

- it is still possible to start applications

When a user session has been opened, then closed, and the user clicks on 
shutdown or reboot from LightDM, the behavior is similar: LightDM does 
not stop. It is even possible to log in again, while unattended-upgrades 
is applying updates, but when updates are applied the computer 
shutdowns/reboots as requested originally from LightDM.


I would expect the session to be completely closed, LightDM stopped, and 
the console or Plymouth displaying a message indicating the ongoing 
updates. I am almost sure this works like this on Ubuntu, with the same 
setup from me. Where should I look to solve this? Should I report a bug, 
and on which package?


Regards,
Yvan


1. Here are the files I create to configure unattended-upgrades:
$ cat /etc/apt/apt.conf.d/21periodic
  APT::Periodic::Unattended-Upgrade "1";
  APT::Periodic::CleanInterval "1";

$ cat /etc/apt/apt.conf.d/51unattended-upgrades-local
Unattended-Upgrade::Origins-Pattern {
  "origin=Debian,codename=bullseye,label=Debian";
  "origin=Debian,codename=bullseye,label=Debian-Security";
  "origin=Debian,codename=bullseye-updates,label=Debian";
};
Unattended-Upgrade::Mail "root";
nattended-Upgrade::InstallOnShutdown "true";
Unattended-Upgrade::Remove-Unused-Kernel-Packages "false";

$ cat /etc/systemd/logind.conf.d/unattended-upgrades.conf
[Login]
# 30 minutes delay
InhibitDelayMaxSec=1800


2. This matches the following error in ~/.xsession-errors:
Cjs-message: 09:26:35.004: JS LOG: Ignored exception from dbus method: 
GIO.IOErrorEnum: GDBus:Error:org.gnome.SessionManager.NotInRunning: 
Shutdown interface is only available during the Running phase




OpenPGP_signature
Description: OpenPGP digital signature

Re: SOLVED: Re: How to add an origin to unattended upgrades?

[Charles Curley]

On Mon, 19 Oct 2020 12:51:20 -0600
Charles Curley  wrote:

> On Fri, 16 Oct 2020 13:24:06 -0600
> Charles Curley  wrote:
> 
> > I have unattended upgrades running on a testbed laptop. I would like
> > to add an origin to the list, but I don't think I am getting the
> > entry quite right. The origin is for vivaldi, which has its own
> > repo outside the Debian repos.  
> 
> On further reflection, I looked at the sample entries for origins, and
> realized that the line for Debian Backports in the Archive or Suite
> section might be a better model to try. After commenting out my
> original effort, I added:
> 
> --
> //  "o=Debian Backports,a=${distro_codename}-backports,l=Debian
> Backports"; "o=Vivaldi Technologies,a=stable,l=Official Vivaldi
> package repository"; };
> --
> 
> This appears to work in a dry run:

This worked in a live run. Vivaldi was updated this morning.

The correct line, not mangled by my mail program, is:

--
//  "o=Debian Backports,a=${distro_codename}-backports,l=Debian Backports";
"o=Vivaldi Technologies,a=stable,l=Official Vivaldi package repository";
};
--

Thanks to Andrei POPESCU  for catching that.

-- 
Does anybody read signatures any more?

https://charlescurley.com
https://charlescurley.com/blog/

Re: SOLVED??: Re: How to add an origin to unattended upgrades?

[Charles Curley]

On Tue, 20 Oct 2020 10:38:20 +0300
Andrei POPESCU  wrote:

> > --
> > //  "o=Debian Backports,a=${distro_codename}-backports,l=Debian
> > Backports"; "o=Vivaldi Technologies,a=stable,l=Official Vivaldi
> > package repository"; };
> > --  
> 
> Did your mail program mangle long lines here?
> 
> For the archives it would be good to repost the correct line(s) that 
> work.

Oops. Thank you for saying something.

--
//  "o=Debian Backports,a=${distro_codename}-backports,l=Debian Backports";
"o=Vivaldi Technologies,a=stable,l=Official Vivaldi package repository";
};
--


-- 
Does anybody read signatures any more?

https://charlescurley.com
https://charlescurley.com/blog/


pgpBhou4kPtk4.pgp
Description: OpenPGP digital signature

Re: SOLVED??: Re: How to add an origin to unattended upgrades?

[Andrei POPESCU]

On Lu, 19 oct 20, 12:51:20, Charles Curley wrote:
> 
> On further reflection, I looked at the sample entries for origins, and
> realized that the line for Debian Backports in the Archive or Suite
> section might be a better model to try. After commenting out my
> original effort, I added:
> 
> --
> //  "o=Debian Backports,a=${distro_codename}-backports,l=Debian
> Backports"; "o=Vivaldi Technologies,a=stable,l=Official Vivaldi package
> repository"; };
> --

Did your mail program mangle long lines here?

For the archives it would be good to repost the correct line(s) that 
work.

Kind regards,
Andrei
-- 
http://wiki.debian.org/FAQsFromDebianUser


signature.asc
Description: PGP signature

SOLVED??: Re: How to add an origin to unattended upgrades?

[Charles Curley]

On Fri, 16 Oct 2020 13:24:06 -0600
Charles Curley  wrote:

> I have unattended upgrades running on a testbed laptop. I would like
> to add an origin to the list, but I don't think I am getting the entry
> quite right. The origin is for vivaldi, which has its own repo outside
> the Debian repos.

On further reflection, I looked at the sample entries for origins, and
realized that the line for Debian Backports in the Archive or Suite
section might be a better model to try. After commenting out my
original effort, I added:

--
//  "o=Debian Backports,a=${distro_codename}-backports,l=Debian
Backports"; "o=Vivaldi Technologies,a=stable,l=Official Vivaldi package
repository"; };
--

This appears to work in a dry run:

------
root@orca:~# unattended-upgrades --dry-run -d
Initial blacklist : 
Initial whitelist: 
Starting unattended upgrades script
Allowed origins are: origin=Debian,codename=buster-updates,
origin=Debian,codename=buster,label=Debian,
origin=Debian,codename=buster,label=Debian-Security, o=Vivaldi
Technologies,a=stable,l=Official Vivaldi package repository Using
(^linux-image-[0-9]+\.[0-9\.]+-.*|^linux-headers-[0-9]+\.[0-9\.]+-.*|^linux-image-extra-[0-9]+\.[0-9\.]+-.*|^linux-modules-[0-9]+\.[0-9\.]+-.*|^linux-modules-extra-[0-9]+\.[0-9\.]+-.*|^linux-signed-image-[0-9]+\.[0-9\.]+-.*|^linux-image-unsigned-[0-9]+\.[0-9\.]+-.*|^kfreebsd-image-[0-9]+\.[0-9\.]+-.*|^kfreebsd-headers-[0-9]+\.[0-9\.]+-.*|^gnumach-image-[0-9]+\.[0-9\.]+-.*|^.*-modules-[0-9]+\.[0-9\.]+-.*|^.*-kernel-[0-9]+\.[0-9\.]+-.*|^linux-backports-modules-.*-[0-9]+\.[0-9\.]+-.*|^linux-modules-.*-[0-9]+\.[0-9\.]+-.*|^linux-tools-[0-9]+\.[0-9\.]+-.*|^linux-cloud-tools-[0-9]+\.[0-9\.]+-.*|^linux-buildinfo-[0-9]+\.[0-9\.]+-.*|^linux-source-[0-9]+\.[0-9\.]+-.*)
regexp to find kernel packages Using
(^linux-image-4\.19\.0\-11\-amd64$|^linux-headers-4\.19\.0\-11\-amd64$|^linux-image-extra-4\.19\.0\-11\-amd64$|^linux-modules-4\.19\.0\-11\-amd64$|^linux-modules-extra-4\.19\.0\-11\-amd64$|^linux-signed-image-4\.19\.0\-11\-amd64$|^linux-image-unsigned-4\.19\.0\-11\-amd64$|^kfreebsd-image-4\.19\.0\-11\-amd64$|^kfreebsd-headers-4\.19\.0\-11\-amd64$|^gnumach-image-4\.19\.0\-11\-amd64$|^.*-modules-4\.19\.0\-11\-amd64$|^.*-kernel-4\.19\.0\-11\-amd64$|^linux-backports-modules-.*-4\.19\.0\-11\-amd64$|^linux-modules-.*-4\.19\.0\-11\-amd64$|^linux-tools-4\.19\.0\-11\-amd64$|^linux-cloud-tools-4\.19\.0\-11\-amd64$|^linux-buildinfo-4\.19\.0\-11\-amd64$|^linux-source-4\.19\.0\-11\-amd64$)
regexp to find running kernel packages Checking: linux-image-amd64
([])
Checking: linux-libc-dev ([]) Checking: vivaldi-stable ([]) pkgs that
look like they should be upgraded: linux-image-amd64 linux-libc-dev
vivaldi-stable Get:1 http://repo.vivaldi.com/stable/deb stable/main
amd64 vivaldi-stable amd64 3.4.2066.76-1 [75.7 MB] Fetched 75.7 MB in
6s (14.6 MB/s) fetch.run() result: 0 http://repo.vivaldi.com/stable/deb/pool/main/vivaldi-stable_3.4.2066.76-1_amd64.deb'
ID:1 ErrorText: ''>
check_conffile_prompt(/var/cache/apt/archives/vivaldi-stable_3.4.2066.76-1_amd64.deb)
found pkg: vivaldi-stable No conffiles in
deb /var/cache/apt/archives/vivaldi-stable_3.4.2066.76-1_amd64.deb
(There is no member named 'conffiles') http://security.debian.org/debian-security/pool/updates/main/l/linux-signed-amd64/linux-image-4.19.0-12-amd64_4.19.152-1_amd64.deb'
ID:0 ErrorText: ''>
check_conffile_prompt(/var/cache/apt/archives/linux-image-4.19.0-12-amd64_4.19.152-1_amd64.deb)
No conffiles in
deb /var/cache/apt/archives/linux-image-4.19.0-12-amd64_4.19.152-1_amd64.deb
(There is no member named 'conffiles') http://security.debian.org/debian-security/pool/updates/main/l/linux-latest/linux-image-amd64_4.19+105+deb10u7_amd64.deb'
ID:0 ErrorText: ''>
check_conffile_prompt(/var/cache/apt/archives/linux-image-amd64_4.19+105+deb10u7_amd64.deb)
found pkg: linux-image-amd64 No conffiles in
deb /var/cache/apt/archives/linux-image-amd64_4.19+105+deb10u7_amd64.deb
(There is no member named 'conffiles') http://security.debian.org/debian-security/pool/updates/main/l/linux/linux-libc-dev_4.19.152-1_amd64.deb'
ID:0 ErrorText: ''>
check_conffile_prompt(/var/cache/apt/archives/linux-libc-dev_4.19.152-1_amd64.deb)
found pkg: linux-libc-dev No conffiles in
deb /var/cache/apt/archives/linux-libc-dev_4.19.152-1_amd64.deb (There
is no member named 'conffiles') blacklist: [] whitelist: [] Option
--dry-run given, *not* performing real actions Packages that will be
upgraded: linux-image-amd64 linux-libc-dev vivaldi-stable Writing dpkg
log to /var/log/unattended-upgrades/unattended-upgrades-dpkg.log
applying set ['linux-image-4.19.0-12-amd64', 'linux-image-amd64']
apt-listchanges: Reading changelogs... /usr/bin/dpkg --status-fd 11
--no-triggers --unpack
--auto-deconfigure 
/var/cache/apt/archives/linux-image-4.19.0-12-amd64_4.19.152-1_am

Re: How to add an origin to unattended upgrades?

[Charles Curley]

On Sun, 18 Oct 2020 13:29:26 +0300
Andrei POPESCU  wrote:

> This looks good to me.
> 
> After looking through the bugs list for unattended-upgrades I would 
> suggest you check whether upgrading vivaldi-stable requires
> installing new packages or package removals ('apt upgrade -s' should
> tell), as this will also block the upgrade (by design, see #645382).

--
root@orca:~# apt upgrade -s
Reading package lists... Done
Building dependency tree   
Reading state information... Done
Calculating upgrade... Done
The following NEW packages will be installed:
  linux-image-4.19.0-12-amd64
The following packages will be upgraded:
  linux-image-amd64 linux-libc-dev vivaldi-stable
3 upgraded, 1 newly installed, 0 to remove and 0 not upgraded.
Inst vivaldi-stable [3.1.1929.45-1] (3.4.2066.76-1 Official Vivaldi package 
repository:stable [amd64])
Inst linux-image-4.19.0-12-amd64 (4.19.152-1 Debian-Security:10/stable [amd64])
Inst linux-image-amd64 [4.19+105+deb10u6] (4.19+105+deb10u7 
Debian-Security:10/stable [amd64])
Inst linux-libc-dev [4.19.146-1] (4.19.152-1 Debian-Security:10/stable [amd64])
Conf vivaldi-stable (3.4.2066.76-1 Official Vivaldi package repository:stable 
[amd64])
Conf linux-image-4.19.0-12-amd64 (4.19.152-1 Debian-Security:10/stable [amd64])
Conf linux-image-amd64 (4.19+105+deb10u7 Debian-Security:10/stable [amd64])
Conf linux-libc-dev (4.19.152-1 Debian-Security:10/stable [amd64])
root@orca:~# 
--

It looks to me like a straight upgrade with no removals.


> 
> I'm also not quite sure about the spaces in the origin and label. The 
> log suggests they are interpreted correctly, though you could try 
> escaping them (the submitter in #940151 is using ', ' to separate the 
> fields, which might be the cause for his issues).

I figured from the supplied origins that they are comma delimited, but
your point about spaces is a good one. I tried that.

--
"origin='Vivaldi Technologies',codename=stable,label='Official Vivaldi 
package repository'";
--

------
root@orca:~# unattended-upgrades --dry-run -d
Initial blacklist : 
Initial whitelist: 
Starting unattended upgrades script
Allowed origins are: origin=Debian,codename=buster-updates, 
origin=Debian,codename=buster,label=Debian, 
origin=Debian,codename=buster,label=Debian-Security, origin='Vivaldi 
Technologies',codename=stable,label='Official Vivaldi package repository'
Using 
(^linux-image-[0-9]+\.[0-9\.]+-.*|^linux-headers-[0-9]+\.[0-9\.]+-.*|^linux-image-extra-[0-9]+\.[0-9\.]+-.*|^linux-modules-[0-9]+\.[0-9\.]+-.*|^linux-modules-extra-[0-9]+\.[0-9\.]+-.*|^linux-signed-image-[0-9]+\.[0-9\.]+-.*|^linux-image-unsigned-[0-9]+\.[0-9\.]+-.*|^kfreebsd-image-[0-9]+\.[0-9\.]+-.*|^kfreebsd-headers-[0-9]+\.[0-9\.]+-.*|^gnumach-image-[0-9]+\.[0-9\.]+-.*|^.*-modules-[0-9]+\.[0-9\.]+-.*|^.*-kernel-[0-9]+\.[0-9\.]+-.*|^linux-backports-modules-.*-[0-9]+\.[0-9\.]+-.*|^linux-modules-.*-[0-9]+\.[0-9\.]+-.*|^linux-tools-[0-9]+\.[0-9\.]+-.*|^linux-cloud-tools-[0-9]+\.[0-9\.]+-.*|^linux-buildinfo-[0-9]+\.[0-9\.]+-.*|^linux-source-[0-9]+\.[0-9\.]+-.*)
 regexp to find kernel packages
Using 
(^linux-image-4\.19\.0\-11\-amd64$|^linux-headers-4\.19\.0\-11\-amd64$|^linux-image-extra-4\.19\.0\-11\-amd64$|^linux-modules-4\.19\.0\-11\-amd64$|^linux-modules-extra-4\.19\.0\-11\-amd64$|^linux-signed-image-4\.19\.0\-11\-amd64$|^linux-image-unsigned-4\.19\.0\-11\-amd64$|^kfreebsd-image-4\.19\.0\-11\-amd64$|^kfreebsd-headers-4\.19\.0\-11\-amd64$|^gnumach-image-4\.19\.0\-11\-amd64$|^.*-modules-4\.19\.0\-11\-amd64$|^.*-kernel-4\.19\.0\-11\-amd64$|^linux-backports-modules-.*-4\.19\.0\-11\-amd64$|^linux-modules-.*-4\.19\.0\-11\-amd64$|^linux-tools-4\.19\.0\-11\-amd64$|^linux-cloud-tools-4\.19\.0\-11\-amd64$|^linux-buildinfo-4\.19\.0\-11\-amd64$|^linux-source-4\.19\.0\-11\-amd64$)
 regexp to find running kernel packages
Checking: linux-image-amd64 ([])
Checking: linux-libc-dev ([])
Checking: vivaldi-stable ([])
pkgs that look like they should be upgraded: linux-image-amd64
linux-libc-dev
Fetched 0 B in 0s (0 B/s)   
   
fetch.run() result: 0
http://security.debian.org/debian-security/pool/updates/main/l/linux-signed-amd64/linux-image-4.19.0-12-amd64_4.19.152-1_amd64.deb'
 ID:0 ErrorText: ''>
check_conffile_prompt(/var/cache/apt/archives/linux-image-4.19.0-12-amd64_4.19.152-1_amd64.deb)
No conffiles in deb 
/var/cache/apt/archives/linux-image-4.19.0-12-amd64_4.19.152-1_amd64.deb (There 
is no member named 'conffiles')
http://security.debian.org/debian-security/pool/updates/main/l/linux-latest/linux-image-amd64_4.19+105+deb10u7_amd64.deb'
 ID:0 ErrorText: ''>
check_conffile_prompt(/var/cache/apt/

Re: How to add an origin to unattended upgrades?

[Andrei POPESCU]

On Sb, 17 oct 20, 07:34:53, Charles Curley wrote:
> On Sat, 17 Oct 2020 09:21:22 +0300
> Andrei POPESCU  wrote:
> 
> > Please show also the output of 'apt policy vivaldi' (or whatever the 
> > package name is).
> 
> --
> root@orca:~# apt policy vivaldi-stable
> vivaldi-stable:
>   Installed: 3.1.1929.45-1
>   Candidate: 3.4.2066.76-1
>   Version table:
>  3.4.2066.76-1 500
> 500 http://repo.vivaldi.com/stable/deb stable/main amd64 Packages
>  *** 3.1.1929.45-1 100
> 100 /var/lib/dpkg/status
> root@orca:~# 
> --

This looks good to me.

After looking through the bugs list for unattended-upgrades I would 
suggest you check whether upgrading vivaldi-stable requires installing 
new packages or package removals ('apt upgrade -s' should tell), as this 
will also block the upgrade (by design, see #645382).

I'm also not quite sure about the spaces in the origin and label. The 
log suggests they are interpreted correctly, though you could try 
escaping them (the submitter in #940151 is using ', ' to separate the 
fields, which might be the cause for his issues).

Other that that you could try to debug /usr/bin/unattended-upgrade 
(Python) or contact the maintainer, e.g. via a follow-up to #799754.

Hope this helps,
Andrei
-- 
http://wiki.debian.org/FAQsFromDebianUser


signature.asc
Description: PGP signature

Re: How to add an origin to unattended upgrades?

[Charles Curley]

On Sat, 17 Oct 2020 09:21:22 +0300
Andrei POPESCU  wrote:

> Please show also the output of 'apt policy vivaldi' (or whatever the 
> package name is).

--
root@orca:~# apt policy vivaldi-stable
vivaldi-stable:
  Installed: 3.1.1929.45-1
  Candidate: 3.4.2066.76-1
  Version table:
 3.4.2066.76-1 500
500 http://repo.vivaldi.com/stable/deb stable/main amd64 Packages
 *** 3.1.1929.45-1 100
100 /var/lib/dpkg/status
root@orca:~# 
--


-- 
Does anybody read signatures any more?

https://charlescurley.com
https://charlescurley.com/blog/


pgph9UGxHwfLk.pgp
Description: OpenPGP digital signature

Re: How to add an origin to unattended upgrades?

[Andrei POPESCU]

On Vi, 16 oct 20, 13:24:06, Charles Curley wrote:
> 
> --
> root@orca:~# apt-cache policy | grep -i vivaldi
>  500 http://repo.vivaldi.com/stable/deb stable/main i386 Packages
>  release o=Vivaldi Technologies,a=stable,l=Official Vivaldi package 
> repository,c=main,b=i386
>  origin repo.vivaldi.com
>  500 http://repo.vivaldi.com/stable/deb stable/main amd64 Packages
>  release o=Vivaldi Technologies,a=stable,l=Official Vivaldi package 
> repository,c=main,b=amd64
>  origin repo.vivaldi.com
> root@orca:~# 
> --

Please show also the output of 'apt policy vivaldi' (or whatever the 
package name is).

Kind regards,
Andrei
-- 
http://wiki.debian.org/FAQsFromDebianUser


signature.asc
Description: PGP signature

How to add an origin to unattended upgrades?

[Charles Curley]

I have unattended upgrades running on a testbed laptop. I would like to
add an origin to the list, but I don't think I am getting the entry
quite right. The origin is for vivaldi, which has its own repo outside
the Debian repos.

I set things up according to
https://wiki.debian.org/UnattendedUpgrades, and it works correctly for
Debian origins. The laptop had not been used for several months, so the
next unattended upgrade did a massive upgrade. So far, so good.

I tried adding the vivaldi origin to the mix. Now I cannot find
whatever web page I got the instructions from, but here are the results:

--
root@orca:~# apt-cache policy | grep -i vivaldi
 500 http://repo.vivaldi.com/stable/deb stable/main i386 Packages
 release o=Vivaldi Technologies,a=stable,l=Official Vivaldi package 
repository,c=main,b=i386
 origin repo.vivaldi.com
 500 http://repo.vivaldi.com/stable/deb stable/main amd64 Packages
 release o=Vivaldi Technologies,a=stable,l=Official Vivaldi package 
repository,c=main,b=amd64
 origin repo.vivaldi.com
root@orca:~# 
--

led to the following in /etc/apt/apt.conf.d/50unattended-upgrades:

--
Unattended-Upgrade::Origins-Pattern {
// Codename based matching:
// This will follow the migration of a release through different
// archives (e.g. from testing to stable and later oldstable).
// Software will be the latest available for the named release,
// but the Debian release itself will not be automatically upgraded.
//  "origin=Debian,codename=${distro_codename}-updates";
"origin=Debian,codename=${distro_codename}-updates"; // 2020-06-16
//  "origin=Debian,codename=${distro_codename}-proposed-updates";
"origin=Debian,codename=${distro_codename},label=Debian";
"origin=Debian,codename=${distro_codename},label=Debian-Security";
"origin=Vivaldi Technologies,codename=stable,label=Official Vivaldi 
package repository";

// Archive or Suite based matching:
// Note that this will silently match a different release after
// migration to the specified archive (e.g. testing becomes the
// new stable).
//  "o=Debian,a=stable";
//  "o=Debian,a=stable-updates";
//  "o=Debian,a=proposed-updates";
//  "o=Debian Backports,a=${distro_codename}-backports,l=Debian Backports";
};
------

There is an upgrade pending for Vivaldi, and the package has been
downloaded. But unattended upgrades has not installed it.

------
root@orca:~# unattended-upgrades --dry-run -d
Initial blacklist : 
Initial whitelist: 
Starting unattended upgrades script
Allowed origins are: origin=Debian,codename=buster-updates, 
origin=Debian,codename=buster,label=Debian, 
origin=Debian,codename=buster,label=Debian-Security, origin=Vivaldi 
Technologies,codename=stable,label=Official Vivaldi package repository
Using 
(^linux-image-[0-9]+\.[0-9\.]+-.*|^linux-headers-[0-9]+\.[0-9\.]+-.*|^linux-image-extra-[0-9]+\.[0-9\.]+-.*|^linux-modules-[0-9]+\.[0-9\.]+-.*|^linux-modules-extra-[0-9]+\.[0-9\.]+-.*|^linux-signed-image-[0-9]+\.[0-9\.]+-.*|^linux-image-unsigned-[0-9]+\.[0-9\.]+-.*|^kfreebsd-image-[0-9]+\.[0-9\.]+-.*|^kfreebsd-headers-[0-9]+\.[0-9\.]+-.*|^gnumach-image-[0-9]+\.[0-9\.]+-.*|^.*-modules-[0-9]+\.[0-9\.]+-.*|^.*-kernel-[0-9]+\.[0-9\.]+-.*|^linux-backports-modules-.*-[0-9]+\.[0-9\.]+-.*|^linux-modules-.*-[0-9]+\.[0-9\.]+-.*|^linux-tools-[0-9]+\.[0-9\.]+-.*|^linux-cloud-tools-[0-9]+\.[0-9\.]+-.*|^linux-buildinfo-[0-9]+\.[0-9\.]+-.*|^linux-source-[0-9]+\.[0-9\.]+-.*)
 regexp to find kernel packages
Using 
(^linux-image-4\.19\.0\-11\-amd64$|^linux-headers-4\.19\.0\-11\-amd64$|^linux-image-extra-4\.19\.0\-11\-amd64$|^linux-modules-4\.19\.0\-11\-amd64$|^linux-modules-extra-4\.19\.0\-11\-amd64$|^linux-signed-image-4\.19\.0\-11\-amd64$|^linux-image-unsigned-4\.19\.0\-11\-amd64$|^kfreebsd-image-4\.19\.0\-11\-amd64$|^kfreebsd-headers-4\.19\.0\-11\-amd64$|^gnumach-image-4\.19\.0\-11\-amd64$|^.*-modules-4\.19\.0\-11\-amd64$|^.*-kernel-4\.19\.0\-11\-amd64$|^linux-backports-modules-.*-4\.19\.0\-11\-amd64$|^linux-modules-.*-4\.19\.0\-11\-amd64$|^linux-tools-4\.19\.0\-11\-amd64$|^linux-cloud-tools-4\.19\.0\-11\-amd64$|^linux-buildinfo-4\.19\.0\-11\-amd64$|^linux-source-4\.19\.0\-11\-amd64$)
 regexp to find running kernel packages
Checking: vivaldi-stable ([])
pkgs that look like they should be upgraded: 
Fetched 0 B in 0s (0 B/s)
fetch.run() result: 0
blacklist: []
whitelist: []
No packages found that can be upgraded unattended and no pending auto-removals
root@orca:~# 
--


-- 
Does anybody read signatures any more?

https://charlescurley.com
https://charlescurley.com/blog/

Re: Atualizações automáticas unattended-upgrades

[Leandro Guimarães Faria Corcete DUTRA]

Le mercredi 10 juin 2020 à 11:05 -0300, P. J. a écrit :
> geralmente o reboot é associado ao kernel oq não é
> muito frequente no stable.

Mesmo uma atualização do núcleo não exige reinicar, porque o
novo núcleo instala-se ao lado do antigo.  Obviamente lançamento
contínuo não é adequado para servidores.


-- 
/¯\ skype:leandro.gfc.dutra?chat  Yahoo!: ymsgr:sendIM?lgcdutra
\ / +55 (61) 3546 7191 xmpp:leand...@jabber.org
 X  +55 (61) 99302 2691   ICQ/AIM: aim:GoIM?screenname=61287803
/ \ BRAZIL GMT−3  https://useplaintext.email/#why-plaintext

Re: Atualizações automáticas unattended-upgrades

[P. J.]

Olá,

Particularmente não curto atualizações automáticas nem no meu desktop
uso. Tipo eu geralmente acompanho as atualizações com o apticron nos
servidores e uma ou duas vezes no mês faço as atualizações a depender
da criticidade, geralmente o reboot é associado ao kernel oq não é
muito frequente no stable.

Existem muitas variáveis envolvidas. Tipo tenho que obedecer o SLA,
por tanto não posso correr risco de algum serviço/servidor ficar fora
do ar sem ter sido acordado (ex: solicitação de mudança). Mas repito
depende de autonomia sua e qnt de impacto negativo terá no seu negócio
ficar fora do ar.

Em 10/06/2020, Sérgio Abrantes escreveu:
> Olá pessoal,
>
> Atualmente faço atualizações manualmente de servidores.
> Tenho receio de problemas com atualizações automáticas pelo
> unattended-upgrades. Nunca usei.
> Queria saber se vocês utilizam, se já utilizaram, se da problema, etc.
> Também dá pra configurar reboot automático. Vocês utilizam esse recurso ou
> reiniciam na mão?
>
> Obrigado!
>
> Sérgio Abrantes
>


-- 
|  .''`.   A fé não dá respostas. Só impede perguntas.
| : :'  :
| `. `'`
|   `-   Je vois tout

Atualizações automáticas unattended-upgrades

[Sérgio Abrantes]

Olá pessoal,

Atualmente faço atualizações manualmente de servidores.
Tenho receio de problemas com atualizações automáticas pelo
unattended-upgrades. Nunca usei.
Queria saber se vocês utilizam, se já utilizaram, se da problema, etc.
Também dá pra configurar reboot automático. Vocês utilizam esse recurso ou
reiniciam na mão?

Obrigado!

Sérgio Abrantes

Re: Question on Unattended Upgrades

[Marco Möller]

On 12.05.20 07:25, Keifer Bly wrote:
Is there a way to configure it to automatically restart when a package 
that needs to be restarted is upgraded? Thx.


Restarting might not be needed at all if applying some "live patching" 
mechanism. It might not be helpful for you, but I thought to mention it 
for the sake of completeness.
Searching online quickly let find several solution providers, and my 
impression it that setting it up and running it is not as trivial and 
fast as simply taking your time to (manually or automatically) trigger a 
reboot for a few systems. The benefit might come for bigger server 
farms, though.

Gene Heskett some 2 years ago nicely considered about it here on the list:
https://lists.debian.org/debian-user/2018/06/msg00702.html

Re: Question on Unattended Upgrades

[l0f4r0]

Hi,

13 mai 2020 à 06:39 de keifer@gmail.com:

> I am not backing this machine up to a physical drive, it is a VPS, so being 
> hosted in the cloud and all. We are not dealing with databases, but just 
> pushing traffic between nodes, etc. They strongly advise be running both the 
> most secure version of the OS and their software at all times, that's why I 
> am wanting to update them both automatically. Thanks very much.
>
Personnally, I would deactivate the automatic reboot after upgrading but make 
sure an email is sent to me after each upgrade.
>From memory, "reboot needed" or something like that is indicated inside this 
>email when required so you can manually & precisely deal with the situation 
>yourself afterwards.

Best regards,
l0f4r0

Re: Question on Unattended Upgrades

[Gene Heskett]

On Wednesday 13 May 2020 03:53:36 l0f...@tuta.io wrote:

> Hi,
>
> 13 mai 2020 à 06:39 de keifer@gmail.com:
> > I am not backing this machine up to a physical drive, it is a VPS,
> > so being hosted in the cloud and all. We are not dealing with
> > databases, but just pushing traffic between nodes, etc. They
> > strongly advise be running both the most secure version of the OS
> > and their software at all times, that's why I am wanting to update
> > them both automatically. Thanks very much.
>
> Personnally, I would deactivate the automatic reboot after upgrading
> but make sure an email is sent to me after each upgrade. From memory,
> "reboot needed" or something like that is indicated inside this email
> when required so you can manually & precisely deal with the situation
> yourself afterwards.
>
> Best regards,
> l0f4r0

That would make the most sense.

Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
If we desire respect for the law, we must first make the law respectable.
 - Louis D. Brandeis
Genes Web page 

Re: Question on Unattended Upgrades

[Gene Heskett]

On Tuesday 12 May 2020 22:49:48 Tom Dial wrote:

> On 5/12/20 09:05, Gene Heskett wrote:
> > On Tuesday 12 May 2020 10:30:04 Celejar wrote:
> >> On Tue, 12 May 2020 06:03:52 -0400
> >>
> >> Gene Heskett  wrote:
> >>> On Tuesday 12 May 2020 05:07:04 l0f...@tuta.io wrote:
> >>>> Hi,
> >>>>
> >>>> 12 mai 2020 à 08:22 de keifer@gmail.com:
> >>>>> Is there a way to configure it to automatically restart when a
> >>>>> package that needs to be restarted is upgraded?
> >>>>
> >>>> I think 'Unattended-Upgrade::Automatic-Reboot "true";' should do
> >>>> it in /etc/apt/apt.conf.d/50unattended-upgrades. If I were you, I
> >>>> would check /etc/apt/apt.conf.d/20auto-upgrades as well because
> >>>> those are the 2 most important configuration files for
> >>>> unattended-upgrades.
> >>>>
> >>>> Best regards,
> >>>> l0f4r0
> >>>
> >>> I can see a major disaster in the making, what if that reboot was
> >>> commanded in the middle of your nightly backup run, leaving your
> >>> backup program with a totally bogus database it cannot recover
> >>> from?
> >>
> >> That would be unfortunate - but surely a serious backup program
> >> would be designed to be robust enough that ending up "with a
> >> totally bogus database it cannot recover from" should never happen?
> >> What if you have some sort of system crash during a backup? Do you
> >> have a specific backup system in mind?
> >
> > You are trying to justify an automatic reboot, very bad idea.
> > Granted, most such would be ok, and will leave a requester popup to
> > advise the admin, doing its normal routine in the meantime.
> >
> > I happen to use amanda to backup 5 machines here, but any backup
> > suite that maintains a recovery database is going to be in deep
> > doodoo if it gets rebooted in the middle of a backup.  I probably do
> > better than most but a worst case scenario here if everything in
> > place works, would only lose me that days data because I do keep
> > separate copies of that data. But 60 days of that is 33GB, the
> > biggest single entry in my nearly 70 items long list.
>
> I don't know about Amanda other than understanding it to be a
> commercial quality backup system. In my working days as an
> administrator, my organization used HP Data Protector (now Micro
> Focus). As I recall, it had a proprietary transactional database that
> should have been up to date as of the last successfully completed file
> backups before a crash. It also, at least in our usage, backed up its
> database as the first action in a cycle, so in the worst case,
> reloading the database and rerunning the faulted backup would restore
> synchronization of the database and data. And if all else failed, I
> think there were procedures for rebuilding the database from the
> tapes. I wonder if Amanda does not provide similar features.
>
> We also did not do automatic updates, there being organizational
> requirements to test configuration changes before installing them on
> production systems.
>
> I don't consider automatic updates a very good idea, although out of
> laziness in retirement I allow automatic security updates. Unplanned
> reboots seem an even worse idea inasmuch as they occasionally will
> either fail or affect system function. (Updating without rebooting
> also may do that, of course).
>
> >>> Frankly the update shouldn't be allowed if your backup is actually
> >>> running.  So it might be safer to schedule the update and reboot
> >>> if needed before the backup starts.  That means one cron driven
> >>> script does it all in the sequence desired.
>
> With respect, I would run the backup first and schedule upgrades and
> possible reboots to follow, and perhaps depend on success of, the
> backup.
>
> Regards,
> Tom Dial
>
We are in violent agreement on that. I've never done an "automatic" 
upgrade, although apt does do a update to keep its database as to whats 
available automaticly.  The only fault with the list --upgradeable 
output is that it does not filter out what is pinned, which on the other 
4 machines here, is the kernel and its libs because its a special 
realtime built kernel for running cnc machinery.  So they don't often 
get rebooted unless something has obviously screwed the moose. X related 
stuff for instance often qualifies.  Although x development's pace has 
slowed, the gui's it makes possible hasn't.

As far as amanda's database is concerned, until the backup has been done, 
that database is effectively yesterdays, so I wrote a wrapper that 
appends that now up to date database to the just completed backup so the 
database in THAT backup is up to date.  Gives me a little more peace of 
mind.

Thanks, stay well and safe now.

Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
If we desire respect for the law, we must first make the law respectable.
 - Louis D. Brandeis
Genes Web page <http://geneslinuxbox.net:6309/gene>

Re: Question on Unattended Upgrades

[Keifer Bly]

I am not backing this machine up to a physical drive, it is a VPS, so being
hosted in the cloud and all. We are not dealing with databases, but just
pushing traffic between nodes, etc. They strongly advise be running both
the most secure version of the OS and their software at all times, that's
why I am wanting to update them both automatically. Thanks very much.
--Keifer


On Tue, May 12, 2020 at 8:06 PM Tom Dial  wrote:

>
>
> On 5/12/20 09:05, Gene Heskett wrote:
> > On Tuesday 12 May 2020 10:30:04 Celejar wrote:
> >
> >> On Tue, 12 May 2020 06:03:52 -0400
> >>
> >> Gene Heskett  wrote:
> >>> On Tuesday 12 May 2020 05:07:04 l0f...@tuta.io wrote:
> >>>> Hi,
> >>>>
> >>>> 12 mai 2020 à 08:22 de keifer@gmail.com:
> >>>>> Is there a way to configure it to automatically restart when a
> >>>>> package that needs to be restarted is upgraded?
> >>>>
> >>>> I think 'Unattended-Upgrade::Automatic-Reboot "true";' should do
> >>>> it in /etc/apt/apt.conf.d/50unattended-upgrades. If I were you, I
> >>>> would check /etc/apt/apt.conf.d/20auto-upgrades as well because
> >>>> those are the 2 most important configuration files for
> >>>> unattended-upgrades.
> >>>>
> >>>> Best regards,
> >>>> l0f4r0
> >>>
> >>> I can see a major disaster in the making, what if that reboot was
> >>> commanded in the middle of your nightly backup run, leaving your
> >>> backup program with a totally bogus database it cannot recover from?
> >>
> >> That would be unfortunate - but surely a serious backup program would
> >> be designed to be robust enough that ending up "with a totally bogus
> >> database it cannot recover from" should never happen? What if you
> >> have some sort of system crash during a backup? Do you have a specific
> >> backup system in mind?
> >
> > You are trying to justify an automatic reboot, very bad idea. Granted,
> > most such would be ok, and will leave a requester popup to advise the
> > admin, doing its normal routine in the meantime.
> >
> > I happen to use amanda to backup 5 machines here, but any backup suite
> > that maintains a recovery database is going to be in deep doodoo if it
> > gets rebooted in the middle of a backup.  I probably do better than most
> > but a worst case scenario here if everything in place works, would only
> > lose me that days data because I do keep separate copies of that data.
> > But 60 days of that is 33GB, the biggest single entry in my nearly 70
> > items long list.
> >
>
> I don't know about Amanda other than understanding it to be a commercial
> quality backup system. In my working days as an administrator, my
> organization used HP Data Protector (now Micro Focus). As I recall, it
> had a proprietary transactional database that should have been up to
> date as of the last successfully completed file backups before a crash.
> It also, at least in our usage, backed up its database as the first
> action in a cycle, so in the worst case, reloading the database and
> rerunning the faulted backup would restore synchronization of the
> database and data. And if all else failed, I think there were procedures
> for rebuilding the database from the tapes. I wonder if Amanda does not
> provide similar features.
>
> We also did not do automatic updates, there being organizational
> requirements to test configuration changes before installing them on
> production systems.
>
> I don't consider automatic updates a very good idea, although out of
> laziness in retirement I allow automatic security updates. Unplanned
> reboots seem an even worse idea inasmuch as they occasionally will
> either fail or affect system function. (Updating without rebooting also
> may do that, of course).
>
> >>> Frankly the update shouldn't be allowed if your backup is actually
> >>> running.  So it might be safer to schedule the update and reboot if
> >>> needed before the backup starts.  That means one cron driven script
> >>> does it all in the sequence desired.
>
> With respect, I would run the backup first and schedule upgrades and
> possible reboots to follow, and perhaps depend on success of, the backup.
>
> Regards,
> Tom Dial
>
> >
> > Cheers, Gene Heskett
> >
>
>

Re: Question on Unattended Upgrades

[Tom Dial]

On 5/12/20 09:05, Gene Heskett wrote:
> On Tuesday 12 May 2020 10:30:04 Celejar wrote:
> 
>> On Tue, 12 May 2020 06:03:52 -0400
>>
>> Gene Heskett  wrote:
>>> On Tuesday 12 May 2020 05:07:04 l0f...@tuta.io wrote:
>>>> Hi,
>>>>
>>>> 12 mai 2020 à 08:22 de keifer@gmail.com:
>>>>> Is there a way to configure it to automatically restart when a
>>>>> package that needs to be restarted is upgraded?
>>>>
>>>> I think 'Unattended-Upgrade::Automatic-Reboot "true";' should do
>>>> it in /etc/apt/apt.conf.d/50unattended-upgrades. If I were you, I
>>>> would check /etc/apt/apt.conf.d/20auto-upgrades as well because
>>>> those are the 2 most important configuration files for
>>>> unattended-upgrades.
>>>>
>>>> Best regards,
>>>> l0f4r0
>>>
>>> I can see a major disaster in the making, what if that reboot was
>>> commanded in the middle of your nightly backup run, leaving your
>>> backup program with a totally bogus database it cannot recover from?
>>
>> That would be unfortunate - but surely a serious backup program would
>> be designed to be robust enough that ending up "with a totally bogus
>> database it cannot recover from" should never happen? What if you
>> have some sort of system crash during a backup? Do you have a specific
>> backup system in mind?
> 
> You are trying to justify an automatic reboot, very bad idea. Granted, 
> most such would be ok, and will leave a requester popup to advise the 
> admin, doing its normal routine in the meantime.
> 
> I happen to use amanda to backup 5 machines here, but any backup suite 
> that maintains a recovery database is going to be in deep doodoo if it 
> gets rebooted in the middle of a backup.  I probably do better than most 
> but a worst case scenario here if everything in place works, would only 
> lose me that days data because I do keep separate copies of that data. 
> But 60 days of that is 33GB, the biggest single entry in my nearly 70 
> items long list.
> 

I don't know about Amanda other than understanding it to be a commercial
quality backup system. In my working days as an administrator, my
organization used HP Data Protector (now Micro Focus). As I recall, it
had a proprietary transactional database that should have been up to
date as of the last successfully completed file backups before a crash.
It also, at least in our usage, backed up its database as the first
action in a cycle, so in the worst case, reloading the database and
rerunning the faulted backup would restore synchronization of the
database and data. And if all else failed, I think there were procedures
for rebuilding the database from the tapes. I wonder if Amanda does not
provide similar features.

We also did not do automatic updates, there being organizational
requirements to test configuration changes before installing them on
production systems.

I don't consider automatic updates a very good idea, although out of
laziness in retirement I allow automatic security updates. Unplanned
reboots seem an even worse idea inasmuch as they occasionally will
either fail or affect system function. (Updating without rebooting also
may do that, of course).

>>> Frankly the update shouldn't be allowed if your backup is actually
>>> running.  So it might be safer to schedule the update and reboot if
>>> needed before the backup starts.  That means one cron driven script
>>> does it all in the sequence desired.

With respect, I would run the backup first and schedule upgrades and
possible reboots to follow, and perhaps depend on success of, the backup.

Regards,
Tom Dial

> 
> Cheers, Gene Heskett
> 

Re: Question on Unattended Upgrades

[Keifer Bly]

Right, so according to i0f...@tutra.io's advice, I changed the line "
 'Unattended-Upgrade::Automatic-Reboot "false" to
'Unattended-Upgrade::Automatic-Reboot
"true" in   /etc/apt/apt.conf.d/50unattended-upgrades. Upon checking
 /etc/apt/apt.conf.d/20auto-upgrades I see the lines:

APT::Periodic::Update-Package-Lists "1";
APT::Periodic::Unattended-Upgrade "1";

What I am doing is running a small web server via a Debian Linux VPS, which
I am trying to use Unattended Upgrades to keep the software for this web
server and he OS Kernel up to date automatically. Based on what I see it
looks like it is working. Will this restart the OS and all processes I have
to restart via Chron automatically?  Thx.




--Keifer


<https://www.avast.com/sig-email?utm_medium=email_source=link_campaign=sig-email_content=webmail_term=icon>
Virus-free.
www.avast.com
<https://www.avast.com/sig-email?utm_medium=email_source=link_campaign=sig-email_content=webmail_term=link>
<#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>

On Tue, May 12, 2020 at 2:07 AM  wrote:

> Hi,
>
> 12 mai 2020 à 08:22 de keifer@gmail.com:
>
> > Is there a way to configure it to automatically restart when a package
> that needs to be restarted is upgraded?
> >
> I think 'Unattended-Upgrade::Automatic-Reboot "true";' should do it
> in /etc/apt/apt.conf.d/50unattended-upgrades.
> If I were you, I would check /etc/apt/apt.conf.d/20auto-upgrades as well
> because those are the 2 most important configuration files for
> unattended-upgrades.
>
> Best regards,
> l0f4r0
>
>

Re: Question on Unattended Upgrades

[l0f4r0]

Hi,

12 mai 2020 à 23:44 de cov...@ccs.covici.com:

> Hmmm, I looked in man apt.conf and for the periodic options it said to
> look in /usr/lib/apt/apt.systemd.daily and that script does not
> mention the option you mentioned.  Is there some other place I should
> look for its description?
>
APT::Periodic::Unattended-Upgrade "1"; enables "apt upgrade" itself.More 
details on:
* https://wiki.debian.org/UnattendedUpgrades.
* man unattended-upgrades
* /usr/share/doc/unattended-upgrades/README.md.gz

Best regards,
l0f4r0

Re: Question on Unattended Upgrades

[John Covici]

Hmmm, I looked in man apt.conf and for the periodic options it said to
look in /usr/lib/apt/apt.systemd.daily and that script does not
mention the option you mentioned.  Is there some other place I should
look for its description?


On Tue, 12 May 2020 16:47:33 -0400,
David Wright wrote:
> 
> On Tue 12 May 2020 at 15:14:51 (-0400), John Covici wrote:
> > To get back to the topic -- I have unattended updates set supposedly,
> > but they do nothing.
> > 
> > Here are the relevant files from my apt.conf.d directory
> > 
> > 20-auto-upgrades
> > apt::periodic::unattended-upgrade "1";
> > 
> > Here is my 50-unattended-upgrades
> > […]
> 
> You appear to have removed the line
> 
> APT::Periodic::Update-Package-Lists "1";
> 
> from 20-auto-upgrades. Is something else responsible for updating them?
> 
> Also, I assume that there's no 20auto-upgrades-disabled present.
> 
> Disclaimer: I don't use the package, so I'm only looking at the
> /usr/share/unattended-upgrades/ files which probably get modified
> during installation.
> 
> Cheers,
> David.
> 

-- 
Your life is like a penny.  You're going to lose it.  The question is:
How do
you spend it?

 John Covici wb2una
 cov...@ccs.covici.com

Re: Question on Unattended Upgrades

[David Wright]

On Tue 12 May 2020 at 15:14:51 (-0400), John Covici wrote:
> To get back to the topic -- I have unattended updates set supposedly,
> but they do nothing.
> 
> Here are the relevant files from my apt.conf.d directory
> 
> 20-auto-upgrades
> apt::periodic::unattended-upgrade "1";
> 
> Here is my 50-unattended-upgrades
> […]

You appear to have removed the line

APT::Periodic::Update-Package-Lists "1";

from 20-auto-upgrades. Is something else responsible for updating them?

Also, I assume that there's no 20auto-upgrades-disabled present.

Disclaimer: I don't use the package, so I'm only looking at the
/usr/share/unattended-upgrades/ files which probably get modified
during installation.

Cheers,
David.

Re: Question on Unattended Upgrades

[John Covici]

To get back to the topic -- I have unattended updates set supposedly,
but they do nothing.

Here are the relevant files from my apt.conf.d directory

20-auto-upgrades
apt::periodic::unattended-upgrade "1";

Here is my 50-unattended-upgrades

// Unattended-Upgrade::Origins-Pattern controls which packages are
// upgraded.
//
// Lines below have the format format is "keyword=value,...".  A
// package will be upgraded only if the values in its metadata match
// all the supplied keywords in a line.  (In other words, omitted
// keywords are wild cards.) The keywords originate from the Release
// file, but several aliases are accepted.  The accepted keywords are:
//   a,archive,suite (eg, "stable")
//   c,component (eg, "main", "contrib", "non-free")
//   l,label (eg, "Debian", "Debian-Security")
//   o,origin(eg, "Debian", "Unofficial Multimedia Packages")
//   n,codename  (eg, "jessie", "jessie-updates")
// site  (eg, "http.debian.net")
// The available values on the system are printed by the command
// "apt-cache policy", and can be debugged by running
// "unattended-upgrades -d" and looking at the log file.
//
// Within lines unattended-upgrades allows 2 macros whose values are
// derived from /etc/debian_version:
//   ${distro_id}Installed origin.
//   ${distro_codename}  Installed codename (eg, "buster")
Unattended-Upgrade::Origins-Pattern {
// Codename based matching:
// This will follow the migration of a release through different
// archives (e.g. from testing to stable and later oldstable).
// Software will be the latest available for the named release,
// but the Debian release itself will not be automatically upgraded.
//  "origin=Debian,codename=${distro_codename}-updates";
//  "origin=Debian,codename=${distro_codename}-proposed-updates";
"origin=Debian,codename=${distro_codename},label=Debian";
"origin=Debian,codename=${distro_codename},label=Debian-Security";

// Archive or Suite based matching:
// Note that this will silently match a different release after
// migration to the specified archive (e.g. testing becomes the
// new stable).
//  "o=Debian,a=stable";
//  "o=Debian,a=stable-updates";
//  "o=Debian,a=proposed-updates";
//  "o=Debian Backports,a=${distro_codename}-backports,l=Debian Backports";
};

// Python regular expressions, matching packages to exclude from upgrading
Unattended-Upgrade::Package-Blacklist {
// The following matches all packages starting with linux-
//  "linux-";

// Use $ to explicitely define the end of a package name. Without
// the $, "libc6" would match all of them.
//  "libc6$";
//  "libc6-dev$";
//  "libc6-i686$";

// Special characters need escaping
//  "libstdc\+\+6$";

// The following matches packages like xen-system-amd64, xen-utils-4.1,
// xenstore-utils and libxenstore3.0
//  "(lib)?xen(store)?";

// For more information about Python regular expressions, see
// https://docs.python.org/3/howto/regex.html
};

// This option allows you to control if on a unclean dpkg exit
// unattended-upgrades will automatically run 
//   dpkg --force-confold --configure -a
// The default is true, to ensure updates keep getting installed
//Unattended-Upgrade::AutoFixInterruptedDpkg "true";

// Split the upgrade into the smallest possible chunks so that
// they can be interrupted with SIGTERM. This makes the upgrade
// a bit slower but it has the benefit that shutdown while a upgrade
// is running is possible (with a small delay)
//Unattended-Upgrade::MinimalSteps "true";

// Install all updates when the machine is shutting down
// instead of doing it in the background while the machine is running.
// This will (obviously) make shutdown slower.
// Unattended-upgrades increases logind's InhibitDelayMaxSec to 30s.
// This allows more time for unattended-upgrades to shut down gracefully
// or even install a few packages in InstallOnShutdown mode, but is still a
// big step back from the 30 minutes allowed for InstallOnShutdown previously.
// Users enabling InstallOnShutdown mode are advised to increase
// InhibitDelayMaxSec even further, possibly to 30 minutes.
Unattended-Upgrade::InstallOnShutdown "false";

// Send email to this address for problems or packages upgrades
// If empty or unset then no email is sent, make sure that you
// have a working mail setup on your system. A package that provides
// 'mailx' must be installed. E.g. "u...@example.com"
Unattended-Upgrade::Mail "cov...@ccs.covici.com";

// Set this value to "

Re: Question on Unattended Upgrades

[David Wright]

On Tue 12 May 2020 at 07:48:49 (-0400), rhkra...@gmail.com wrote:
> On Tuesday, May 12, 2020 02:22:13 AM Keifer Bly wrote:
> > Is there a way to configure it to automatically restart when a package that
> > needs to be restarted is upgraded? Thx.
> 
> If there is a comand named "needrestart" (I don't see it on my Wheezy 
> system), 
> then presumably a (bash?) script could be written to automate a restart.

It's in backports.

Cheers,
David.

Re: Question on Unattended Upgrades

[Celejar]

On Tue, 12 May 2020 11:05:55 -0400
Gene Heskett  wrote:

> On Tuesday 12 May 2020 10:30:04 Celejar wrote:
> 
> > On Tue, 12 May 2020 06:03:52 -0400
> >
> > Gene Heskett  wrote:
> > > On Tuesday 12 May 2020 05:07:04 l0f...@tuta.io wrote:
> > > > Hi,
> > > >
> > > > 12 mai 2020 à 08:22 de keifer@gmail.com:
> > > > > Is there a way to configure it to automatically restart when a
> > > > > package that needs to be restarted is upgraded?
> > > >
> > > > I think 'Unattended-Upgrade::Automatic-Reboot "true";' should do
> > > > it in /etc/apt/apt.conf.d/50unattended-upgrades. If I were you, I
> > > > would check /etc/apt/apt.conf.d/20auto-upgrades as well because
> > > > those are the 2 most important configuration files for
> > > > unattended-upgrades.
> > > >
> > > > Best regards,
> > > > l0f4r0
> > >
> > > I can see a major disaster in the making, what if that reboot was
> > > commanded in the middle of your nightly backup run, leaving your
> > > backup program with a totally bogus database it cannot recover from?
> >
> > That would be unfortunate - but surely a serious backup program would
> > be designed to be robust enough that ending up "with a totally bogus
> > database it cannot recover from" should never happen? What if you
> > have some sort of system crash during a backup? Do you have a specific
> > backup system in mind?
> 
> You are trying to justify an automatic reboot, very bad idea. Granted, 
> most such would be ok, and will leave a requester popup to advise the 
> admin, doing its normal routine in the meantime.

I'm not trying to justify an automatic reboot; I'm just questioning the
specific dire scenario you mention.

> I happen to use amanda to backup 5 machines here, but any backup suite 
> that maintains a recovery database is going to be in deep doodoo if it 
> gets rebooted in the middle of a backup.  I probably do better than most 

Surely any "recovery database" used by a serious backup program is
atomic!

> but a worst case scenario here if everything in place works, would only 
> lose me that days data because I do keep separate copies of that data. 
> But 60 days of that is 33GB, the biggest single entry in my nearly 70 
> items long list.

Celejar

Re: Question on Unattended Upgrades

[Gene Heskett]

On Tuesday 12 May 2020 10:30:04 Celejar wrote:

> On Tue, 12 May 2020 06:03:52 -0400
>
> Gene Heskett  wrote:
> > On Tuesday 12 May 2020 05:07:04 l0f...@tuta.io wrote:
> > > Hi,
> > >
> > > 12 mai 2020 à 08:22 de keifer@gmail.com:
> > > > Is there a way to configure it to automatically restart when a
> > > > package that needs to be restarted is upgraded?
> > >
> > > I think 'Unattended-Upgrade::Automatic-Reboot "true";' should do
> > > it in /etc/apt/apt.conf.d/50unattended-upgrades. If I were you, I
> > > would check /etc/apt/apt.conf.d/20auto-upgrades as well because
> > > those are the 2 most important configuration files for
> > > unattended-upgrades.
> > >
> > > Best regards,
> > > l0f4r0
> >
> > I can see a major disaster in the making, what if that reboot was
> > commanded in the middle of your nightly backup run, leaving your
> > backup program with a totally bogus database it cannot recover from?
>
> That would be unfortunate - but surely a serious backup program would
> be designed to be robust enough that ending up "with a totally bogus
> database it cannot recover from" should never happen? What if you
> have some sort of system crash during a backup? Do you have a specific
> backup system in mind?

You are trying to justify an automatic reboot, very bad idea. Granted, 
most such would be ok, and will leave a requester popup to advise the 
admin, doing its normal routine in the meantime.

I happen to use amanda to backup 5 machines here, but any backup suite 
that maintains a recovery database is going to be in deep doodoo if it 
gets rebooted in the middle of a backup.  I probably do better than most 
but a worst case scenario here if everything in place works, would only 
lose me that days data because I do keep separate copies of that data. 
But 60 days of that is 33GB, the biggest single entry in my nearly 70 
items long list.

> > Frankly the update shouldn't be allowed if your backup is actually
> > running.  So it might be safer to schedule the update and reboot if
> > needed before the backup starts.  That means one cron driven script
> > does it all in the sequence desired.

Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
If we desire respect for the law, we must first make the law respectable.
 - Louis D. Brandeis
Genes Web page <http://geneslinuxbox.net:6309/gene>

Re: Question on Unattended Upgrades

[Celejar]

On Tue, 12 May 2020 06:03:52 -0400
Gene Heskett  wrote:

> On Tuesday 12 May 2020 05:07:04 l0f...@tuta.io wrote:
> 
> > Hi,
> >
> > 12 mai 2020 à 08:22 de keifer@gmail.com:
> > > Is there a way to configure it to automatically restart when a
> > > package that needs to be restarted is upgraded?
> >
> > I think 'Unattended-Upgrade::Automatic-Reboot "true";' should do it
> > in /etc/apt/apt.conf.d/50unattended-upgrades. If I were you, I would
> > check /etc/apt/apt.conf.d/20auto-upgrades as well because those are
> > the 2 most important configuration files for unattended-upgrades.
> >
> > Best regards,
> > l0f4r0
> 
> I can see a major disaster in the making, what if that reboot was 
> commanded in the middle of your nightly backup run, leaving your backup 
> program with a totally bogus database it cannot recover from?

That would be unfortunate - but surely a serious backup program would
be designed to be robust enough that ending up "with a totally bogus
database it cannot recover from" should never happen? What if you
have some sort of system crash during a backup? Do you have a specific
backup system in mind?

> Frankly the update shouldn't be allowed if your backup is actually 
> running.  So it might be safer to schedule the update and reboot if 
> needed before the backup starts.  That means one cron driven script does 
> it all in the sequence desired.
> 
> Cheers, Gene Heskett

Celejar

Re: Question on Unattended Upgrades

[John Hasler]

 Keifer Bly writes:
> I am wondering, does the OS need to be restarted for the upgrade to
> take effect?

Only if the kernel was upgraded.

> What file would I check to make sure the unattended upgrades is
> working and the packages it updated?

>From the man page:

All operations are logged to
/var/log/unattended-upgrades/unattended-upgrades.log
and the package manager (dpkg) output is logged to
/var/log/unattended-upgrades/unattended-up‐grades-dpkg.log

You can arrange to get emails by editing
/etc/apt/apt.conf.d/50unattended-upgrades.  Lots other options as well.
-- 
John Hasler 
jhas...@newsguy.com
Elmwood, WI USA

Re: Question on Unattended Upgrades

[Reco]

Hi.

On Tue, May 12, 2020 at 07:48:49AM -0400, rhkra...@gmail.com wrote:
> On Tuesday, May 12, 2020 02:22:13 AM Keifer Bly wrote:
> > Is there a way to configure it to automatically restart when a package that
> > needs to be restarted is upgraded? Thx.
> 
> If there is a comand named "needrestart" (I don't see it on my Wheezy 
> system), 
> then presumably a (bash?) script could be written to automate a restart.

$ file /usr/sbin/needrestart
/usr/sbin/needrestart: Perl script text executable

Appeared in Jessie, still here.

Reco

Re: Question on Unattended Upgrades

[Greg Wooledge]

On Tue, May 12, 2020 at 07:48:49AM -0400, rhkra...@gmail.com wrote:
> On Tuesday, May 12, 2020 02:22:13 AM Keifer Bly wrote:
> > Is there a way to configure it to automatically restart when a package that
> > needs to be restarted is upgraded? Thx.
> 
> If there is a comand named "needrestart" (I don't see it on my Wheezy 
> system), 
The package appears to have been added in jessie.

Re: Question on Unattended Upgrades

[rhkramer]

On Tuesday, May 12, 2020 02:22:13 AM Keifer Bly wrote:
> Is there a way to configure it to automatically restart when a package that
> needs to be restarted is upgraded? Thx.

If there is a comand named "needrestart" (I don't see it on my Wheezy system), 
then presumably a (bash?) script could be written to automate a restart.

(If I did it (which I won't), I'd make it present its results to the user / 
administrator and ask for confirmation, and/or use that command that warns 
users that the system is about to be shut down.)

Re: Question on Unattended Upgrades

[l0f4r0]

Hi,

12 mai 2020 à 12:03 de ghesk...@shentel.net:

> I can see a major disaster in the making, what if that reboot was 
> commanded in the middle of your nightly backup run, leaving your backup 
> program with a totally bogus database it cannot recover from?
>
> Frankly the update shouldn't be allowed if your backup is actually 
> running.  So it might be safer to schedule the update and reboot if 
> needed before the backup starts.  That means one cron driven script does 
> it all in the sequence desired.
>
Of course, nice reminder from Gene, as usual technology doesn't replace common 
sense ;)
Binaries simply execute what you ask them to, they don't see the whole picture 
and what you really intend to do eventually... 

Best regards,
l0f4r0

Re: Question on Unattended Upgrades

[Gene Heskett]

On Tuesday 12 May 2020 05:07:04 l0f...@tuta.io wrote:

> Hi,
>
> 12 mai 2020 à 08:22 de keifer@gmail.com:
> > Is there a way to configure it to automatically restart when a
> > package that needs to be restarted is upgraded?
>
> I think 'Unattended-Upgrade::Automatic-Reboot "true";' should do it
> in /etc/apt/apt.conf.d/50unattended-upgrades. If I were you, I would
> check /etc/apt/apt.conf.d/20auto-upgrades as well because those are
> the 2 most important configuration files for unattended-upgrades.
>
> Best regards,
> l0f4r0

I can see a major disaster in the making, what if that reboot was 
commanded in the middle of your nightly backup run, leaving your backup 
program with a totally bogus database it cannot recover from?

Frankly the update shouldn't be allowed if your backup is actually 
running.  So it might be safer to schedule the update and reboot if 
needed before the backup starts.  That means one cron driven script does 
it all in the sequence desired.

Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
If we desire respect for the law, we must first make the law respectable.
 - Louis D. Brandeis
Genes Web page <http://geneslinuxbox.net:6309/gene>

Re: Question on Unattended Upgrades

[l0f4r0]

Hi,

12 mai 2020 à 08:22 de keifer@gmail.com:

> Is there a way to configure it to automatically restart when a package that 
> needs to be restarted is upgraded?
>
I think 'Unattended-Upgrade::Automatic-Reboot "true";' should do it in 
/etc/apt/apt.conf.d/50unattended-upgrades.
If I were you, I would check /etc/apt/apt.conf.d/20auto-upgrades as well 
because those are the 2 most important configuration files for 
unattended-upgrades.

Best regards,
l0f4r0

Re: Question on Unattended Upgrades

[Keifer Bly]

Is there a way to configure it to automatically restart when a package that
needs to be restarted is upgraded? Thx.
--Keifer


On Mon, May 11, 2020 at 11:14 PM Charles Curley <
charlescur...@charlescurley.com> wrote:

> On Tue, 12 May 2020 11:54:48 +0700
> Victor Sudakov  wrote:
>
> > > Does the OS need to be restarted for this to take effect? Thx.
> >
> > That depends. If the kernel has been upgraded, then probably yes.
> >
> > If some daemon has been upgraded, it could be enough to restart the
> > daemon (or does apt restart it for you automatically? I'm not sure).
> >
> > If some user utility has been upgraded, then reboot is not required.
>
> One way to tell if a restart is required is to run needrestart.
>
> --
> Does anybody read signatures any more?
>
> https://charlescurley.com
> https://charlescurley.com/blog/
>
>

Re: Question on Unattended Upgrades

[Charles Curley]

On Tue, 12 May 2020 11:54:48 +0700
Victor Sudakov  wrote:

> > Does the OS need to be restarted for this to take effect? Thx.  
> 
> That depends. If the kernel has been upgraded, then probably yes. 
> 
> If some daemon has been upgraded, it could be enough to restart the
> daemon (or does apt restart it for you automatically? I'm not sure).
> 
> If some user utility has been upgraded, then reboot is not required.

One way to tell if a restart is required is to run needrestart.

-- 
Does anybody read signatures any more?

https://charlescurley.com
https://charlescurley.com/blog/

Re: Re: Question on Unattended Upgrades

[Keifer Bly]

Is there a way to configure it to automatically restart when a package that
needs to be restarted is upgraded? Thx.

--Keifer



Virus-free.
www.avast.com

<#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>

On Mon, May 11, 2020 at 10:15 PM Keifer Bly  wrote:

> Is there a way to configure it to automatically restart when a package
> that needs to be restarted is upgraded? Thx.
> --Keifer
>
>
>
> 
>  Virus-free.
> www.avast.com
> 
> <#m_-4773324396636007474_DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
>
> On Mon, May 11, 2020 at 9:55 PM Victor Sudakov  wrote:
>
>> Keifer Bly wrote:
>> >So upon doing that, I am seeing this:
>>
>> Please don't use graphics where you could have shown plain text. Not
>> everyone here is using a graphical mail client.
>>
>> >
>> >Does this mean it is updating these automatically?
>>
>> Look for lines matching "Commandline: /usr/bin/unattended-upgrade" in
>> the log. Text under those lines would inform you what unattended-upgrade
>> did automatically. Use
>>
>> grep -A3 unattended-upgrade /var/log/apt/history.log
>>
>>
>> > Does the OS need to be restarted for this to take effect? Thx.
>>
>> That depends. If the kernel has been upgraded, then probably yes.
>>
>> If some daemon has been upgraded, it could be enough to restart the
>> daemon (or does apt restart it for you automatically? I'm not sure).
>>
>> If some user utility has been upgraded, then reboot is not required.
>>
>> --
>> Victor Sudakov,  VAS4-RIPE, VAS47-RIPN
>> 2:5005/49@fidonet http://vas.tomsk.ru/
>>
>>

Re: Re: Question on Unattended Upgrades

[Victor Sudakov]

Keifer Bly wrote:
>So upon doing that, I am seeing this:

Please don't use graphics where you could have shown plain text. Not
everyone here is using a graphical mail client.

> 
>Does this mean it is updating these automatically? 

Look for lines matching "Commandline: /usr/bin/unattended-upgrade" in
the log. Text under those lines would inform you what unattended-upgrade
did automatically. Use 

grep -A3 unattended-upgrade /var/log/apt/history.log


> Does the OS need to be restarted for this to take effect? Thx.

That depends. If the kernel has been upgraded, then probably yes. 

If some daemon has been upgraded, it could be enough to restart the
daemon (or does apt restart it for you automatically? I'm not sure).

If some user utility has been upgraded, then reboot is not required.

-- 
Victor Sudakov,  VAS4-RIPE, VAS47-RIPN
2:5005/49@fidonet http://vas.tomsk.ru/

Re: Question on Unattended Upgrades

[Victor Sudakov]

Keifer Bly wrote:

> What file would
> I check to make sure the unattended upgrades is working and the
> packages it updated? Thanks.

I look for lines matching "Commandline: /usr/bin/unattended-upgrade" in
/var/log/apt/history.log, but there may be a better approach.

-- 
Victor Sudakov,  VAS4-RIPE, VAS47-RIPN
2:5005/49@fidonet http://vas.tomsk.ru/


signature.asc
Description: PGP signature

Question on Unattended Upgrades

[Keifer Bly]

Hello, So I am using unattended upgrades for my Debian Linux OS, as well as a certain package I added to be updated by it. I am wondering, does the OS need to be restarted for the upgrade to take effect? What file would I check to make sure the unattended upgrades is working and the packages it updated? Thanks. Sent from Mail for Windows 10 



	
		
			

			
		
		
			
This email has been checked for viruses by Avast antivirus software.
www.avast.com
			
		
	


 

Re: unattended-upgrades does not install upgrades on shutdown

[Charles Curley]

On Tue, 15 Oct 2019 17:03:19 +1100
Keith Bainbridge  wrote:

> Also, there is a process to get one PC to download the updates, and 
> share that  /var/cache/apt/archives/ to your other PCs

You might look into apt-cacher or apt-cacher-ng for that.

-- 
Does anybody read signatures any more?

https://charlescurley.com
https://charlescurley.com/blog/

Re: unattended-upgrades does not install upgrades on shutdown

[Yvan Masson]

Le 15/10/2019 à 14:10, Curt a écrit :

On 2019-10-15, Yvan Masson  wrote:


I am currently using a VM with snapshots to try to find the culprit, I
will let you know.


I could not find the culprit so I reported the bug:
https://github.com/mvo5/unattended-upgrades/issues/229




There's this (not sure if it's your issue or not):

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=837155

  If /var resides on a separate file-system which is unmounted before
  unattended-upgrade-shutdown is run, it may repeatedly (by default for
  10 minutes) try to acquire it's lock-file but fail since the containing
  folder doesn't exist.

For which the fix is a file
  
  /etc/systemd/system/unattended-upgrades.service.d/mounts.conf


containing

  [Unit]
  RequiresMountsFor=/var/log

Maybe irrelevant. Or not.

A bientôt,

C.

Thanks for the hint, but I have everything in one partition, 
unattended-upgrades stops just after detecting which upgrades are 
available, after 1 or 2 minutes.


Yvan

Re: unattended-upgrades does not install upgrades on shutdown

[Curt]

On 2019-10-15, Yvan Masson  wrote:
>> 
>> I am currently using a VM with snapshots to try to find the culprit, I 
>> will let you know.
>
> I could not find the culprit so I reported the bug:
> https://github.com/mvo5/unattended-upgrades/issues/229
>>>

There's this (not sure if it's your issue or not):

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=837155

 If /var resides on a separate file-system which is unmounted before
 unattended-upgrade-shutdown is run, it may repeatedly (by default for
 10 minutes) try to acquire it's lock-file but fail since the containing
 folder doesn't exist.

For which the fix is a file
 
 /etc/systemd/system/unattended-upgrades.service.d/mounts.conf

containing

 [Unit]
 RequiresMountsFor=/var/log

Maybe irrelevant. Or not. 

A bientôt,

C.

-- 
"There are no foreign lands. It is the traveler only who is foreign."
-- Robert Louis Stevenson

Re: unattended-upgrades does not install upgrades on shutdown

[Yvan Masson]

Le 15/10/2019 à 09:19, Yvan Masson a écrit :

Le 15/10/2019 à 08:03, Keith Bainbridge a écrit :

On 15/10/19 11:31 am, Keith Bainbridge wrote:


How to prevent a repeat is the real question. My only suggestion is 
extend the time-out, but how long.  Maybe run manual upgrades on one 
machine every day, before shutting down the others??



There was a response suggesting getting cron to run something like this:

# apt update  && # apt -dy full-upgrade

Reminded me I did that as well.


I believe the timeout in this case is never reached: computer goes off 
after 1 or 2 minutes, just the time for unattended-upgrades to calculate 
what should be upgraded. Also, unattended-upgrades download packages 
before the computer shuts down.


I am currently using a VM with snapshots to try to find the culprit, I 
will let you know.


I could not find the culprit so I reported the bug:
https://github.com/mvo5/unattended-upgrades/issues/229


Also, there is a process to get one PC to download the updates, and 
share that  /var/cache/apt/archives/ to your other PCs



This would be great, because bandwidth is very slow in this school. What
solution do you think of? Something like apt-cacher-ng on one host?

Re: unattended-upgrades does not install upgrades on shutdown

[Yvan Masson]

Le 15/10/2019 à 08:03, Keith Bainbridge a écrit :

On 15/10/19 11:31 am, Keith Bainbridge wrote:


How to prevent a repeat is the real question. My only suggestion is 
extend the time-out, but how long.  Maybe run manual upgrades on one 
machine every day, before shutting down the others??



There was a response suggesting getting cron to run something like this:

# apt update  && # apt -dy full-upgrade

Reminded me I did that as well.


I believe the timeout in this case is never reached: computer goes off 
after 1 or 2 minutes, just the time for unattended-upgrades to calculate 
what should be upgraded. Also, unattended-upgrades download packages 
before the computer shuts down.


I am currently using a VM with snapshots to try to find the culprit, I 
will let you know.


Also, there is a process to get one PC to download the updates, and 
share that  /var/cache/apt/archives/ to your other PCs



This would be great, because bandwidth is very slow in this school. What
solution do you think of? Something like apt-cacher-ng on one host?

Re: unattended-upgrades does not install upgrades on shutdown

[Keith Bainbridge]

On 15/10/19 11:31 am, Keith Bainbridge wrote:


How to prevent a repeat is the real question. My only suggestion is 
extend the time-out, but how long.  Maybe run manual upgrades on one 
machine every day, before shutting down the others??



There was a response suggesting getting cron to run something like this:

# apt update  && # apt -dy full-upgrade

Reminded me I did that as well.

Also, there is a process to get one PC to download the updates, and 
share that  /var/cache/apt/archives/ to your other PCs



--
Keith Bainbridge

ke1th3...@gmail.com
+61 (0)447 667 468

Re: unattended-upgrades does not install upgrades on shutdown

[Charles Curley]

On Tue, 15 Oct 2019 11:31:22 +1100
Keith Bainbridge  wrote:

> It was intuition rather than any knowledge I had - beyond the fact
> that sometimes upgrade takes longer than normal.
> 
> How to prevent a repeat is the real question.

Upgrades and updates often require fetching across the network, which
can induce network delays. For other reasons entirely, I prefetch my
upgrades so they are on the computer before I start the upgrades. I put
the following into a file in /etc/cron.d:


# cron replaces the percent sign with a new line, so we escape it with a back 
slash.
   5  3  ** *   rootsleep $( echo $((1 + 
RANDOM \% 1200)) ) ; /usr/bin/apt-get update > /dev/null && /usr/bin/apt-get 
-dy dist-upgrade > /dev/null

(Pasted with long lines; your mail client may mangle it.)

You might do something similar before the automatic upgrades occur.

-- 
Does anybody read signatures any more?

https://charlescurley.com
https://charlescurley.com/blog/

Re: unattended-upgrades does not install upgrades on shutdown

[Keith Bainbridge]

On 14/10/19 7:42 pm, Yvan Masson wrote:


You were right Keith: after applying some updates manually, remaining 
updates are
properly installed with unattended-upgrade… Now I need to understand 
what was

blocking.



It was intuition rather than any knowledge I had - beyond the fact that 
sometimes upgrade takes longer than normal.


How to prevent a repeat is the real question. My only suggestion is 
extend the time-out, but how long.  Maybe run manual upgrades on one 
machine every day, before shutting down the others??


--
Keith Bainbridge

ke1th3...@gmail.com
+61 (0)447 667 468

Re: unattended-upgrades does not install upgrades on shutdown

[Yvan Masson]

Le 14/10/2019 à 04:22, Keith Bainbridge a écrit :

On 14/10/19 6:16 am, Yvan Masson wrote:

Hi,

I forgot to tell that I configured another important thing, in 
/etc/systemd/logind.conf:

…
InhibitDelayMaxSec=600
…
Which should let enough time to do the upgrades.

Any hint is very welcome!


Le 12/10/2019 à 18:45, Yvan Masson a écrit :

Hi list,

I configured some Buster desktops in a school to upgrade 
automatically on shutdown via unattended-upgrades. I am almost sure 
it worked at first but it does not anymore. I would really appreciate 
any suggestion as I already spent a few hours on this issue without 
any result.


Symptoms are: shutdown is long (more than 2 minutes), plymouth screen 
shows that unattended-upgrade is running, but no packages are upgraded.


I created /etc/apt/apt.conf.d/51unattended-upgrades-local to store my 
settings (/etc/apt/apt.conf.d/50unattended-upgrades has not been 
modified):

 Unattended-Upgrade::Origins-Pattern {
   "origin=Debian,codename=buster-updates";
   "origin=Debian,codename=buster,label=Debian";
   "origin=Debian,codename=buster,label=Debian-Security";
 };
 Unattended-Upgrade::MinimalSteps "false";
 Unattended-Upgrade::InstallOnShutdown "true";
 Unattended-Upgrade::Verbose "true";
 Unattended-Upgrade::Debug "true";

I created /etc/apt/apt.conf.d/10periodic:
 APT::Periodic::Unattended-Upgrade "1";
 APT::Periodic::Update-Package-Lists "1";
 APT::Periodic::Download-Upgradeable-Packages "1";
 APT::Periodic::AutocleanInterval "7";

For /var/log/unattended-upgrades/unattended-upgrades-shutdown.log, see
https://paste.debian.net/1106125/
For /var/log/unattended-upgrades/unattended-upgrades.log, see
https://paste.debian.net/1106126/
/var/log/unattended-upgrades/unattended-upgrades-dpkg.log is empty.

As you can see, many upgrades are available. Those packages have 
already been downloaded. Where could be my mistake? Could this be a 
bug of the script when too many packages are upgradable (because yes 
it has worked at the very beginning)?


Best regards,
Yvan









Perhaps there was a larger than normal upgrade to exceeded to 10mins 
delay, and it's all stalled



Suggest a manual upgrade to see what results you get.

You were right Keith: after applying some updates manually, remaining 
updates are
properly installed with unattended-upgrade… Now I need to understand 
what was

blocking.

Re: unattended-upgrades does not install upgrades on shutdown

[Keith Bainbridge]

On 14/10/19 6:16 am, Yvan Masson wrote:

Hi,

I forgot to tell that I configured another important thing, in 
/etc/systemd/logind.conf:

…
InhibitDelayMaxSec=600
…
Which should let enough time to do the upgrades.

Any hint is very welcome!


Le 12/10/2019 à 18:45, Yvan Masson a écrit :

Hi list,

I configured some Buster desktops in a school to upgrade automatically 
on shutdown via unattended-upgrades. I am almost sure it worked at 
first but it does not anymore. I would really appreciate any 
suggestion as I already spent a few hours on this issue without any 
result.


Symptoms are: shutdown is long (more than 2 minutes), plymouth screen 
shows that unattended-upgrade is running, but no packages are upgraded.


I created /etc/apt/apt.conf.d/51unattended-upgrades-local to store my 
settings (/etc/apt/apt.conf.d/50unattended-upgrades has not been 
modified):

 Unattended-Upgrade::Origins-Pattern {
   "origin=Debian,codename=buster-updates";
   "origin=Debian,codename=buster,label=Debian";
   "origin=Debian,codename=buster,label=Debian-Security";
 };
 Unattended-Upgrade::MinimalSteps "false";
 Unattended-Upgrade::InstallOnShutdown "true";
 Unattended-Upgrade::Verbose "true";
 Unattended-Upgrade::Debug "true";

I created /etc/apt/apt.conf.d/10periodic:
 APT::Periodic::Unattended-Upgrade "1";
 APT::Periodic::Update-Package-Lists "1";
 APT::Periodic::Download-Upgradeable-Packages "1";
 APT::Periodic::AutocleanInterval "7";

For /var/log/unattended-upgrades/unattended-upgrades-shutdown.log, see
https://paste.debian.net/1106125/
For /var/log/unattended-upgrades/unattended-upgrades.log, see
https://paste.debian.net/1106126/
/var/log/unattended-upgrades/unattended-upgrades-dpkg.log is empty.

As you can see, many upgrades are available. Those packages have 
already been downloaded. Where could be my mistake? Could this be a 
bug of the script when too many packages are upgradable (because yes 
it has worked at the very beginning)?


Best regards,
Yvan









Perhaps there was a larger than normal upgrade to exceeded to 10mins 
delay, and it's all stalled



Suggest a manual upgrade to see what results you get.


--
Keith Bainbridge

ke1th3...@gmail.com
+61 (0)447 667 468

Re: unattended-upgrades does not install upgrades on shutdown

[Yvan Masson]

Hi,

I forgot to tell that I configured another important thing, in 
/etc/systemd/logind.conf:

…
InhibitDelayMaxSec=600
…
Which should let enough time to do the upgrades.

Any hint is very welcome!


Le 12/10/2019 à 18:45, Yvan Masson a écrit :

Hi list,

I configured some Buster desktops in a school to upgrade automatically 
on shutdown via unattended-upgrades. I am almost sure it worked at first 
but it does not anymore. I would really appreciate any suggestion as I 
already spent a few hours on this issue without any result.


Symptoms are: shutdown is long (more than 2 minutes), plymouth screen 
shows that unattended-upgrade is running, but no packages are upgraded.


I created /etc/apt/apt.conf.d/51unattended-upgrades-local to store my 
settings (/etc/apt/apt.conf.d/50unattended-upgrades has not been modified):

     Unattended-Upgrade::Origins-Pattern {
   "origin=Debian,codename=buster-updates";
   "origin=Debian,codename=buster,label=Debian";
   "origin=Debian,codename=buster,label=Debian-Security";
     };
     Unattended-Upgrade::MinimalSteps "false";
     Unattended-Upgrade::InstallOnShutdown "true";
     Unattended-Upgrade::Verbose "true";
     Unattended-Upgrade::Debug "true";

I created /etc/apt/apt.conf.d/10periodic:
     APT::Periodic::Unattended-Upgrade "1";
     APT::Periodic::Update-Package-Lists "1";
     APT::Periodic::Download-Upgradeable-Packages "1";
     APT::Periodic::AutocleanInterval "7";

For /var/log/unattended-upgrades/unattended-upgrades-shutdown.log, see
https://paste.debian.net/1106125/
For /var/log/unattended-upgrades/unattended-upgrades.log, see
https://paste.debian.net/1106126/
/var/log/unattended-upgrades/unattended-upgrades-dpkg.log is empty.

As you can see, many upgrades are available. Those packages have already 
been downloaded. Where could be my mistake? Could this be a bug of the 
script when too many packages are upgradable (because yes it has worked 
at the very beginning)?


Best regards,
Yvan

unattended-upgrades does not install upgrades on shutdown

[Yvan Masson]

Hi list,

I configured some Buster desktops in a school to upgrade automatically 
on shutdown via unattended-upgrades. I am almost sure it worked at first 
but it does not anymore. I would really appreciate any suggestion as I 
already spent a few hours on this issue without any result.


Symptoms are: shutdown is long (more than 2 minutes), plymouth screen 
shows that unattended-upgrade is running, but no packages are upgraded.


I created /etc/apt/apt.conf.d/51unattended-upgrades-local to store my 
settings (/etc/apt/apt.conf.d/50unattended-upgrades has not been modified):

Unattended-Upgrade::Origins-Pattern {
  "origin=Debian,codename=buster-updates";
  "origin=Debian,codename=buster,label=Debian";
  "origin=Debian,codename=buster,label=Debian-Security";
};
Unattended-Upgrade::MinimalSteps "false";
Unattended-Upgrade::InstallOnShutdown "true";
Unattended-Upgrade::Verbose "true";
Unattended-Upgrade::Debug "true";

I created /etc/apt/apt.conf.d/10periodic:
APT::Periodic::Unattended-Upgrade "1";
APT::Periodic::Update-Package-Lists "1";
APT::Periodic::Download-Upgradeable-Packages "1";
APT::Periodic::AutocleanInterval "7";

For /var/log/unattended-upgrades/unattended-upgrades-shutdown.log, see
https://paste.debian.net/1106125/
For /var/log/unattended-upgrades/unattended-upgrades.log, see
https://paste.debian.net/1106126/
/var/log/unattended-upgrades/unattended-upgrades-dpkg.log is empty.

As you can see, many upgrades are available. Those packages have already 
been downloaded. Where could be my mistake? Could this be a bug of the 
script when too many packages are upgradable (because yes it has worked 
at the very beginning)?


Best regards,
Yvan

Re: Differences between apt-listchanges/unattended-upgrades/apticron/cron-apt

[l0f4r0]

Hi,

Thank you very much Dan & Jonas and sorry for the delay...

I think it's pretty clearer now for me.

So in case I want to
A) be notified should there be any new upgrade available
B) have my security packages be ugraded automatically and be notified
C) receive an email with the list of changes 
I will need to install
* apticron for A) and configure /etc/apticron/apticron.conf* unattended-upgrade 
for B) and configure both /etc/apt/apt.conf.d/20auto-upgrades and 
/etc/apt/apt.conf.d/50unattended-upgrades
* apt-listchanges for C) and configure /etc/apt/listchanges.conf

I bet cron-apt (still with apt-listchanges) can do all of this but the 
configuration seems more complex/tricky.

Is that all correct please?
Best regards,
l0f4r0

10 sept. 2019 à 19:05 de l0f...@tuta.io:

> Hello,
>
> Can somebody explain to me the differences between apt-listchanges, 
> unattended-upgrades, apticron and cron-apt please?
>
> I have the following feeling:
> * apt-listchanges: its main purpose is to indicate what's new between 
> different packages versions. So it's handy to learn that new packages are 
> available with an email alert (is it triggered automatically as soon as apt 
> update finds something new?)
>
> * unattended-upgrades: its main purpose is to upgrade your machine 
> automatically. Personally, I use it to update my db & upgrade my vulnerable 
> packages only (btw it triggers apt-listchanges)
>
> Am I correct? Why would I need apticron & cron-apt then (I have Debian 9)?
>
> Thanks in advance!
> l0f4r0
>

Re: Differences between apt-listchanges/unattended-upgrades/apticron/cron-apt

[Dan Ritter]

l0f...@tuta.io wrote: 
> Hello,
> 
> Can somebody explain to me the differences between apt-listchanges, 
> unattended-upgrades, apticron and cron-apt please?
> 
> I have the following feeling:
> * apt-listchanges: its main purpose is to indicate what's new between 
> different packages versions. So it's handy to learn that new packages are 
> available with an email alert (is it triggered automatically as soon as apt 
> update finds something new?)
> 
> * unattended-upgrades: its main purpose is to upgrade your machine 
> automatically. Personally, I use it to update my db & upgrade my vulnerable 
> packages only (btw it triggers apt-listchanges)
> 
> Am I correct? Why would I need apticron & cron-apt then (I have Debian 9)?

apticron automatically downloads packages for updates,
and uses apt-listchanges to generate mail to you about those
updates.

cron-apt competes with apticron, and has the optional ability
to install the upgrades as well as download them. It also uses
apt-listchanges.

unattended-upgrades competes with cron-apt, expects to install 
the upgrades, and will optionally reboot the machine by itself
when it feels it is warranted. It also uses apt-listchanges.

-dsr-

Re: Differences between apt-listchanges/unattended-upgrades/apticron/cron-apt

[Jonas Smedegaard]

Quoting l0f...@tuta.io (2019-09-10 19:05:39)
> Can somebody explain to me the differences between apt-listchanges, 
> unattended-upgrades, apticron and cron-apt please?
> 
> I have the following feeling:
> * apt-listchanges: its main purpose is to indicate what's new between 
> different packages versions. So it's handy to learn that new packages 
> are available with an email alert (is it triggered automatically as 
> soon as apt update finds something new?)

apt-listchanges is triggered as a pre-hook to "apt install" (not as a 
post-hook to "apt update").  By default is shows NEWS entries since the 
already-installed release of same package, but can be changes to 
also/instead show all packaging changes.


> * unattended-upgrades: its main purpose is to upgrade your machine 
> automatically. Personally, I use it to update my db & upgrade my 
> vulnerable packages only (btw it triggers apt-listchanges)
> 
> Am I correct? Why would I need apticron & cron-apt then (I have Debian 
> 9)?

apticron and apt-cron cover similar task as unattended-upgrades.

Related is also needrestart, or needrestart-session for desktop systems.


 - 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

Differences between apt-listchanges/unattended-upgrades/apticron/cron-apt

[l0f4r0]

Hello,

Can somebody explain to me the differences between apt-listchanges, 
unattended-upgrades, apticron and cron-apt please?

I have the following feeling:
* apt-listchanges: its main purpose is to indicate what's new between different 
packages versions. So it's handy to learn that new packages are available with 
an email alert (is it triggered automatically as soon as apt update finds 
something new?)

* unattended-upgrades: its main purpose is to upgrade your machine 
automatically. Personally, I use it to update my db & upgrade my vulnerable 
packages only (btw it triggers apt-listchanges)

Am I correct? Why would I need apticron & cron-apt then (I have Debian 9)?

Thanks in advance!
l0f4r0

Re: unattended-upgrades downloaded package information only from the sources in sources.list.d directory ignoring sources.list file

[Martin T]

Hi,

looks like the culprit is a /etc/cron.daily/do-agent cron-job which
executes the /opt/digitalocean/do-agent/scripts/update.sh script which
includes following if statement:

if command -v apt-get 2&>/dev/null; then
apt-get -qq update -o
Dir::Etc::sourcelist="sources.list.d/digitalocean-agent.list" -o
Dir::Etc::sourceparts="-" -o APT::Get::List-Cleanup="1"
apt-get -qq install -y --only-upgrade do-agent
/* output removed for brevity */

'-o APT::Get::List-Cleanup="1"' flushes other repositories..


Martin

Re: unattended-upgrades downloaded package information only from the sources in sources.list.d directory ignoring sources.list file

[Martin T]

> I did some further debugging and it is the
> /usr/lib/apt/apt.systemd.daily script executed by apt-daily systemd
> service unit which updates the package index from the sources:

I configured cron with one minute interval to log the output of "apt
policy" with a timestamp into a log file in order to understand when
exactly the repository list is messed up. Turns out, that
/usr/lib/apt/apt.systemd.daily script executed by apt-daily systemd
service unit does not mess up the repository list. It happened between
"Sat Jun  8 06:25:01 UTC 2019" and "Sat Jun  8 06:26:01 UTC 2019".
When I check the logs for 06:00 to 06:30 time-period, then following
was logged:

$ sudo journalctl --since "2019-06-08 06:00:00" --until "2019-06-08 06:30:00"
-- Logs begin at Mon 2019-05-13 19:38:07 UTC, end at Sat 2019-06-08
08:11:24 UTC. --
Jun 08 06:25:04 vps systemd[1]: Reloading The Apache HTTP Server.
Jun 08 06:25:05 vps systemd[1]: Reloaded The Apache HTTP Server.
Jun 08 06:25:05 vps liblogging-stdlog[556]:  [origin
software="rsyslogd" swVersion="8.24.0" x-pid="556"
x-info="http://www.rsyslog.com;] rsyslogd was HUPed
$

What and why is sending those signals to processes? Could it somehow
affect the repository list..?


thanks,
Martin

Re: unattended-upgrades downloaded package information only from the sources in sources.list.d directory ignoring sources.list file

[Martin T]

> Looks like the "apt update" or equivalent ran by unattended-upgrades
> ignored the /etc/apt/sources.list file and used only
> /etc/apt/sources.list.d/digitalocean-agent.list as a source for
> repositories.
> What might cause this behavior?

I did some further debugging and it is the
/usr/lib/apt/apt.systemd.daily script executed by apt-daily systemd
service unit which updates the package index from the sources:

# update package lists
UPDATED=0
UPDATE_STAMP=/var/lib/apt/periodic/update-stamp
if check_stamp $UPDATE_STAMP $UpdateInterval; then
if eval apt-get $XAPTOPT -y update $XSTDERR; then
/* output removed fro brevity */


Now I set the APT::Periodic::Verbose value to "2":

$ apt-config dump APT::Periodic::Verbose
APT::Periodic::Verbose "2";
$

..and actually the entries in /etc/apt/sources.list file are not ignored:

$ sudo journalctl --since today --no-pager -u apt-daily
-- Logs begin at Mon 2019-05-13 19:38:07 UTC, end at Thu 2019-06-06
08:40:31 UTC. --
Jun 06 00:49:10 vps systemd[1]: Starting Daily apt download activities...
Jun 06 00:49:10 vps apt.systemd.daily[31062]: verbose level 2
Jun 06 00:49:10 vps apt.systemd.daily[31062]: Reading package lists...
Jun 06 00:49:10 vps apt.systemd.daily[31062]: Building dependency tree...
Jun 06 00:49:10 vps apt.systemd.daily[31062]: Reading state information...
Jun 06 00:49:10 vps apt.systemd.daily[31062]: check_stamp:
interval=86400, now=1559779200, stamp=1559692800, delta=86400 (sec)
Jun 06 00:49:10 vps apt.systemd.daily[31062]: Get:1
http://security.debian.org stretch/updates InRelease [94.3 kB]
Jun 06 00:49:10 vps apt.systemd.daily[31062]: Ign:2
http://mirrors.digitalocean.com/debian stretch InRelease
Jun 06 00:49:10 vps apt.systemd.daily[31062]: Get:3
http://mirrors.digitalocean.com/debian stretch-updates InRelease [91.0
kB]
Jun 06 00:49:10 vps apt.systemd.daily[31062]: Hit:4
http://mirrors.digitalocean.com/debian stretch Release
Jun 06 00:49:10 vps apt.systemd.daily[31062]: Get:5
http://security.debian.org stretch/updates/main Sources [205 kB]
Jun 06 00:49:10 vps apt.systemd.daily[31062]: Get:6
http://security.debian.org stretch/updates/main amd64 Packages [492
kB]
Jun 06 00:49:10 vps apt.systemd.daily[31062]: Get:7
https://repos.insights.digitalocean.com/apt/do-agent main InRelease
[5,132 B]
Jun 06 00:49:10 vps apt.systemd.daily[31062]: Fetched 888 kB in 0s (1,643 kB/s)
Jun 06 00:49:11 vps apt.systemd.daily[31062]: Reading package lists...
Jun 06 00:49:11 vps apt.systemd.daily[31062]: download updated
metadata (success).
Jun 06 00:49:11 vps apt.systemd.daily[31062]: send dbus signal (success)
Jun 06 00:49:11 vps apt.systemd.daily[31062]: check_stamp: interval=0
Jun 06 00:49:11 vps apt.systemd.daily[31062]: download upgradable (not run)
Jun 06 00:49:11 vps apt.systemd.daily[31062]: unattended-upgrade -d (not run)
Jun 06 00:49:11 vps systemd[1]: Started Daily apt download activities.
$

However, again, at the morning "apt policy" listed only the repository
in /etc/apt/sources.list.d/digitalocean-agent.list file:

$ apt policy
Package files:
 100 /var/lib/dpkg/status
 release a=now
 500 https://repos.insights.digitalocean.com/apt/do-agent main/main
amd64 Packages
 release o=. main,a=main,n=main,l=. main,c=main,b=amd64
 origin repos.insights.digitalocean.com
Pinned packages:
$

After running manually the "sudo apt update" command, the apt
downloaded >50MiB of packages data and output of "apt policy" listed
all the repositories.
Log files in /var/log/apt/ directory have not been updated.

What could cause such behavior? How to debug this further?


thanks,
Martin

unattended-upgrades downloaded package information only from the sources in sources.list.d directory ignoring sources.list file

[Martin T]

Hi,

in order to test unattended-upgrades I downgraded yesterday(4.06)
packages iceweasel, qemu-utils and thunderbird:

# # "apt list --upgradable" command below was executed on 4.06
# apt list --upgradable
Listing... Done
iceweasel/stable 60.7.0esr-1~deb9u1 all [upgradable from: 52.9.0esr-1~deb9u1]
qemu-utils/stable 1:2.8+dfsg-6+deb9u6 amd64 [upgradable from:
1:2.8+dfsg-6+deb9u5]
thunderbird/stable 1:60.7.0-1~deb9u1 amd64 [upgradable from: 1:60.6.1-1~deb9u1]
#

As expected, the unattended-upgrades ran today(5.06) morning, but it
reported, that "No packages found that can be upgraded unattended and
no pending auto-removals". Indeed, when I checked for example "apt
policy iceweasel", then the apt saw the installed version as the
latest one:

$ sudo apt policy iceweasel
iceweasel:
  Installed: 52.9.0esr-1~deb9u1
  Candidate: 52.9.0esr-1~deb9u1
  Version table:
 *** 52.9.0esr-1~deb9u1 100
100 /var/lib/dpkg/status
$

"apt policy" listed only the repository configured in
/etc/apt/sources.list.d/digitalocean-agent.list while ignoring the
ones in sources.list:

# apt policy
Package files:
 100 /var/lib/dpkg/status
 release a=now
 500 https://repos.insights.digitalocean.com/apt/do-agent main/main
amd64 Packages
 release o=. main,a=main,n=main,l=. main,c=main,b=amd64
 origin repos.insights.digitalocean.com
Pinned packages:
#

After executing "apt update", the rest of the repositories were again
seen in the output of "apt policy" and for example, the iceweasel was
again upgradable to 60.7.0esr-1~deb9u1:

$ sudo apt policy iceweasel
iceweasel:
  Installed: 52.9.0esr-1~deb9u1
  Candidate: 60.7.0esr-1~deb9u1
/* output removed for brevity */
$

Looks like the "apt update" or equivalent ran by unattended-upgrades
ignored the /etc/apt/sources.list file and used only
/etc/apt/sources.list.d/digitalocean-agent.list as a source for
repositories.
What might cause this behavior?


thanks,
Martin

Re: Unattended Upgrades question

[Brad Rogers]

On Tue, 16 Oct 2018 07:42:56 +0200
john doe  wrote:

Hello john,

>I'll never  understand why being so drastic is a good idea when you can
>simply disable it:

Combinations of the following come to mind.  Could well be more.  No
doubt, you and others can come up with reasons to keep it.  We all make
our own choices, of course.

1) Not everyone likes unattended upgrades.
2) If simply disabled, it can always be accidentally reactivated by an
upgrade (probably not by an unattended one, though).
3) If it's _never_ going to be used, why keep it?

-- 
 Regards  _
 / )   "The blindingly obvious is
/ _)radnever immediately apparent"
Life's short, don't make a mess of it
No Time To Be 21 - The Adverts


pgp0golBqz0Nj.pgp
Description: OpenPGP digital signature