Re: does apt upgrade & full-upgrade packages from Security Updates (Debian Security Advisories (DSA))

[jindam, vani]

On Sun, Nov 13, 2022 at 09:56:21AM +, jindam, vani wrote:
> i have only deb http://deb.debian.org/debian bullseye main contrib non-free 
> in my sources.list. 
> 
> does apt upgrade & full-upgrade packages from Security Updates (Debian 
> Security Advisories (DSA))?

> No, you have to add the security repo to your sources.

> which is correct?
> deb http://security.debian.org/debian-security bullseye-security main contrib 
> non-free (1)
> deb http://deb.debian.org/debian-security/ bullseye-security main contrib 
> non-free

I think it's the first one.

yes, thank you. both README.security (1)(2) on security.debian & deb.debian 
say samething... interesting. debian wiki (3) says 
otherwise, perhaps need to update it.

regards,
jindam, vani

toots: @jindam_v...@c.im
others: en.wikipedia.org/wiki/User:Jindam_vani


(1) http://deb.debian.org/debian-security/README.security
(2) https://security.debian.org/debian-security/README.security
(3) https://wiki.debian.org/SourcesList

> Cheers
>-- 
>t

Re: does apt upgrade & full-upgrade packages from Security Updates (Debian Security Advisories (DSA))

[tomas]

On Sun, Nov 13, 2022 at 09:56:21AM +, jindam, vani wrote:
> i have only deb http://deb.debian.org/debian bullseye main contrib non-free 
> in my sources.list. 
> 
> does apt upgrade & full-upgrade packages from Security Updates (Debian 
> Security Advisories (DSA))?

No, you have to add the security repo to your sources.

> which is correct?
> deb http://security.debian.org/debian-security bullseye-security main contrib 
> non-free (1)
> deb http://deb.debian.org/debian-security/ bullseye-security main contrib 
> non-free

I think it's the first one.

Cheers
-- 
t


signature.asc
Description: PGP signature

does apt upgrade & full-upgrade packages from Security Updates (Debian Security Advisories (DSA))

[jindam, vani]

i have only deb http://deb.debian.org/debian bullseye main contrib non-free in 
my sources.list. 

does apt upgrade & full-upgrade packages from Security Updates (Debian Security 
Advisories (DSA))?

which is correct?
deb http://security.debian.org/debian-security bullseye-security main contrib 
non-free (1)
deb http://deb.debian.org/debian-security/ bullseye-security main contrib 
non-free


(1) https://www.debian.org/security/

regards,
jindam, vani

toots: @jindam_v...@c.im
others: en.wikipedia.org/wiki/User:Jindam_vani

Re: Security Updates

[David Wright]

On Wed 09 Mar 2022 at 21:46:45 (-0500), Greg Wooledge wrote:
> On Wed, Mar 09, 2022 at 08:28:39PM -0500, Dan Ritter wrote:
> > Dimitrios Papanikolaou wrote: 
> > > 
> > > I have Debian 10 (buster) installed in my Nodes.
> > > I use the sec repo:
> > > 
> > > deb http://security.debian.org/debian-securitybuster/updates main contrib 
> > > non-free
> > 
> > I hope there is another / between security and buster.
> 
> You mean a space.
> 
> > > This is what I have. But can you explain me. Why I am not getting the 
> > > latest security updates?
> 
> What specific update did you expect to see, that you did not get?
> 
> > Today you should be getting a new linux kernel.
> 
> In buster?  It's not vulnerable to "dirty-pipe".  That vulnerability
> was introduced in Linux 5.8, and buster has a 4.x kernel.

Start-Date: 2022-03-07  08:23:15
Commandline: apt-get upgrade
Upgrade: firefox-esr-l10n-en-gb:amd64 (91.6.0esr-1~deb10u1, 
91.6.1esr-1~deb10u1), firefox-esr:amd64 (91.6.0esr-1~deb10u1, 
91.6.1esr-1~deb10u1)
End-Date: 2022-03-07  08:23:42

… so the previous browser version ran for about 25 days, …

Start-Date: 2022-03-09  12:14:48
Commandline: apt-get upgrade
Upgrade: linux-libc-dev:amd64 (4.19.208-1, 4.19.232-1), 
linux-compiler-gcc-8-x86:amd64 (4.19.208-1, 4.19.232-1), linux-doc:amd64 
(4.19+105+deb10u13, 4.19+105+deb10u14), linux-source:amd64 (4.19+105+deb10u13, 
4.19+105+deb10u14), linux-doc-4.19:amd64 (4.19.208-1, 4.19.232-1), 
linux-kbuild-4.19:amd64 (4.19.208-1, 4.19.232-1), linux-config-4.19:amd64 
(4.19.208-1, 4.19.232-1), linux-source-4.19:amd64 (4.19.208-1, 4.19.232-1)
End-Date: 2022-03-09  12:15:10

Start-Date: 2022-03-09  12:22:09
Commandline: apt-get dist-upgrade
Install: linux-headers-4.19.0-19-common:amd64 (4.19.232-1, automatic), 
linux-headers-4.19.0-19-amd64:amd64 (4.19.232-1, automatic), 
linux-image-4.19.0-19-amd64:amd64 (4.19.232-1, automatic)
Upgrade: linux-image-amd64:amd64 (4.19+105+deb10u13, 4.19+105+deb10u14), 
linux-headers-amd64:amd64 (4.19+105+deb10u13, 4.19+105+deb10u14)
End-Date: 2022-03-09  12:23:47

… and 5 months for the previous kernel. Could be coincidental.

Cheers,
David.

Re: Security Updates

[Greg Wooledge]

On Wed, Mar 09, 2022 at 08:28:39PM -0500, Dan Ritter wrote:
> Dimitrios Papanikolaou wrote: 
> > Hi,
> > 
> > I have Debian 10 (buster) installed in my Nodes.
> > I use the sec repo:
> > 
> > deb http://security.debian.org/debian-securitybuster/updates main contrib 
> > non-free
> 
> I hope there is another / between security and buster.

You mean a space.

> > This is what I have. But can you explain me. Why I am not getting the 
> > latest security updates?

What specific update did you expect to see, that you did not get?

> Today you should be getting a new linux kernel.

In buster?  It's not vulnerable to "dirty-pipe".  That vulnerability
was introduced in Linux 5.8, and buster has a 4.x kernel.

Re: Security Updates

[Dan Ritter]

Dimitrios Papanikolaou wrote: 
> Hi,
> 
> I have Debian 10 (buster) installed in my Nodes.
> I use the sec repo:
> 
> deb http://security.debian.org/debian-securitybuster/updates main contrib 
> non-free

I hope there is another / between security and buster.
 
> This is what I have. But can you explain me. Why I am not getting the latest 
> security updates?


Today you should be getting a new linux kernel. However, buster
is the old release, and bullseye is the new stable release.
Only significant security updates will be made for the old
system.


-dsr-

Security Updates

[Dimitrios Papanikolaou]

Hi,

I have Debian 10 (buster) installed in my Nodes.
I use the sec repo:

deb http://security.debian.org/debian-securitybuster/updates main contrib 
non-free

This is what I have. But can you explain me. Why I am not getting the latest 
security updates?
Today I updated the Debian Nodes. But nothing new upgraded or installed. But 
there are new security updates like spip or containerd, which I had to install 
them manually.

What should I do to have the latest sec updates?
Any advice is highly appreciated.

Best Regards,
Dimitris

Αποκτήστε το Outlook για iOS<https://aka.ms/o0ukef>

Re: Definitive instructions for Buster LTS security updates

[Keith Christian]

> The OP is tilting at windmills.
>
> The example I posted has been used every three hours of my waking day
> for the past 2½ years. It fails when my cable company fails.
>
> The OP has quoted some hearsay off the web, period. And not a single
> reference with it. The OP calls this "pre-startup research", and
> will "verify [ … ] your suggestions" when the Oracle has handed down
> "the correct sources.list".
>
> Until then, the Buster machine will stay de-activated, the OP remains
> safe, and we await the Oracle.
>
> (Those who know their Classical history will realise that advice
> pulled from the Internet can be as ambiguous as the Oracle always was.)
>
> Cheers,
> David.

David,

Windmills, LOL.  I've always liked that one.
I brought up the old Buster machine and it's working fine with one mod
to he original sources list, uncommenting this line:
   deb http://security.debian.org/debian-security buster/updates main
Since I didn't know that Buster was not yet in LTS, and that there are
no changes needed, I thought I should ask first in case there were
repo changes.
Thanks for your comments.

Keith

Re: Definitive instructions for Buster LTS security updates

[David Wright]

On Tue 22 Feb 2022 at 13:50:20 (+), Tixy wrote:
> On Tue, 2022-02-22 at 06:00 -0700, Keith Christian wrote:
> > On Mon, Feb 21, 2022 at 7:33 AM Tixy  wrote:
> > > I assume because Buster isn't in Long Term Support yet, it's still in
> > > normal support by the security team. From the schedule on the wiki,
> > > it's due to go into LTS this July.
> > 
> > I remembered that I made a copy of the original sources.list file on
> > the day of install.
> > Here it is, I wonder why the security line failed to verify (Line 11) ?
> > The entire sources.list appears below.
> > 
> > # Line commented out by installer because it failed to verify:
> > #deb http://security.debian.org/debian-security buster/updates main
> > 
> > It seems this line should be uncommented?
> > 
> > #deb http://security.debian.org/debian-security buster/updates main
> 
> I just tried that URL and did an 'apt update' and it seemed to work,
> there were no errors and seemed to be download a new package list.
> Interesting that the one I had doesn't have the 'debian-security' bit.
> 
> Also, the online examples of sources.list for Buster have the URL
> 'http://deb.debian.org/debian-security', I beleive that uses the CDN.
> 
> So, for me, all three of these seem work...
> 
> deb http://security.debian.org/ buster/updates main
> deb http://security.debian.org/debian-security buster/updates main
> deb http://deb.debian.org/debian-security buster/updates main

The OP is tilting at windmills.

The example I posted has been used every three hours of my waking day
for the past 2½ years. It fails when my cable company fails.

The OP has quoted some hearsay off the web, period. And not a single
reference with it. The OP calls this "pre-startup research", and
will "verify [ … ] your suggestions" when the Oracle has handed down
"the correct sources.list".

Until then, the Buster machine will stay de-activated, the OP remains
safe, and we await the Oracle.

(Those who know their Classical history will realise that advice
pulled from the Internet can be as ambiguous as the Oracle always was.)

Cheers,
David.

Re: Definitive instructions for Buster LTS security updates

[Tixy]

On Tue, 2022-02-22 at 06:00 -0700, Keith Christian wrote:
> On Mon, Feb 21, 2022 at 7:33 AM Tixy  wrote:
> > I assume because Buster isn't in Long Term Support yet, it's still in
> > normal support by the security team. From the schedule on the wiki,
> > it's due to go into LTS this July.
> 
> Thanks Tixy,
> 
> I remembered that I made a copy of the original sources.list file on
> the day of install.
> Here it is, I wonder why the security line failed to verify (Line 11) ?
> The entire sources.list appears below.
> 
> # Line commented out by installer because it failed to verify:
> #deb http://security.debian.org/debian-security buster/updates main
> 
> It seems this line should be uncommented?
> 
> #deb http://security.debian.org/debian-security buster/updates main

I just tried that URL and did an 'apt update' and it seemed to work,
there were no errors and seemed to be download a new package list.
Interesting that the one I had doesn't have the 'debian-security' bit.

Also, the online examples of sources.list for Buster have the URL
'http://deb.debian.org/debian-security', I beleive that uses the CDN.

So, for me, all three of these seem work...

deb http://security.debian.org/ buster/updates main
deb http://security.debian.org/debian-security buster/updates main
deb http://deb.debian.org/debian-security buster/updates main

-- 
Tixy 

Re: Definitive instructions for Buster LTS security updates

[Greg Wooledge]

On Tue, Feb 22, 2022 at 06:00:53AM -0700, Keith Christian wrote:
> On Mon, Feb 21, 2022 at 7:33 AM Tixy  wrote:
> > I assume because Buster isn't in Long Term Support yet, it's still in
> > normal support by the security team. From the schedule on the wiki,
> > it's due to go into LTS this July.
> 
> Thanks Tixy,
> 
> I remembered that I made a copy of the original sources.list file on
> the day of install.
> Here it is, I wonder why the security line failed to verify (Line 11) ?
> The entire sources.list appears below.
> 
> # Line commented out by installer because it failed to verify:
> #deb http://security.debian.org/debian-security buster/updates main

Only someone who was present for the installation would know for sure,
but at the time, the installer was unable to contact that web site.
Could have been due to missing network interface firmware, or a transient
DNS problem, or ... who knows?

> It seems this line should be uncommented?
> 
> #deb http://security.debian.org/debian-security buster/updates main

Yes.

> 
> =LISTING START
> $ cat /etc/apt/sources.list.orig
> #
> 
> # deb cdrom:[Official Debian GNU/Linux Live 10.0.0 kde
> 2019-07-06T10:52]/ buster main
> 
> #deb cdrom:[Official Debian GNU/Linux Live 10.0.0 kde
> 2019-07-06T10:52]/ buster main
> 
> deb http://deb.debian.org/debian/ buster main
> deb-src http://deb.debian.org/debian/ buster main

But that one worked?  Interesting.  That points more toward an issue
with DNS or with the (small) set of security.debian.org servers, rather
than something like missing firmware which would have affected all
network activity during the installation.

Re: Definitive instructions for Buster LTS security updates

[Keith Christian]

On Mon, Feb 21, 2022 at 7:33 AM Tixy  wrote:
> I assume because Buster isn't in Long Term Support yet, it's still in
> normal support by the security team. From the schedule on the wiki,
> it's due to go into LTS this July.

Thanks Tixy,

I remembered that I made a copy of the original sources.list file on
the day of install.
Here it is, I wonder why the security line failed to verify (Line 11) ?
The entire sources.list appears below.

# Line commented out by installer because it failed to verify:
#deb http://security.debian.org/debian-security buster/updates main

It seems this line should be uncommented?

#deb http://security.debian.org/debian-security buster/updates main

=LISTING START
$ cat /etc/apt/sources.list.orig
#

# deb cdrom:[Official Debian GNU/Linux Live 10.0.0 kde
2019-07-06T10:52]/ buster main

#deb cdrom:[Official Debian GNU/Linux Live 10.0.0 kde
2019-07-06T10:52]/ buster main

deb http://deb.debian.org/debian/ buster main
deb-src http://deb.debian.org/debian/ buster main

# Line commented out by installer because it failed to verify:
#deb http://security.debian.org/debian-security buster/updates main
# Line commented out by installer because it failed to verify:
#deb-src http://security.debian.org/debian-security buster/updates main

# buster-updates, previously known as 'volatile'
# Line commented out by installer because it failed to verify:
#deb http://deb.debian.org/debian/ buster-updates main
# Line commented out by installer because it failed to verify:
#deb-src http://deb.debian.org/debian/ buster-updates main

# This system was installed using small removable media
# (e.g. netinst, live or single CD). The matching "deb cdrom"
# entries were disabled at the end of the installation process.
# For information about how to configure apt package sources,
# see the sources.list(5) manual.
=LISTING END

Keith

Re: Definitive instructions for Buster LTS security updates

[Andrew M.A. Cater]

On Mon, Feb 21, 2022 at 04:28:33PM +0100, Christian Britz wrote:
> 
> 
> On 2022-02-21 15:45 UTC+0100, David Wright wrote:
> 
> > AFAICT, running buster, nothing has yet changed. My sources.list
> > is attached (ignore the first line), and as of this morning it
> > yields:
> And I think nothing will change in the future. Take the Stretch example
> at https://wiki.debian.org/LTS/Using. The sources.list stayed the same.
> Maybe buster-updates will disappear, I do not know how this is handled.
> 
> IMO it makes totally sense to leave this unchanged - every system will
> automatically benefit from LTS.
> 

Things may change in the future - but as it stands, Buster is oldstable
and therefore supported for a year after the release of Bullseye with
no change in sources.list.

It should stay supported until 20220714 this way.

All the very best, as ever,

Andy Cater


> -- 
> http://www.cb-fraggle.de
> 

Re: Definitive instructions for Buster LTS security updates

[Tixy]

On Mon, 2022-02-21 at 15:48 +, Tixy wrote:
> On Mon, 2022-02-21 at 08:16 -0700, Keith Christian wrote:
> > The Buster machine I'm planning to re-activate is still powered off
> > until I find the exact security update lines for sources.list.
> 
> These won't have changed since you first installed Buster. As I said in
> my other reply, Buster isn't yet in Long Term Support, it's still
> getting updates from Debian's security team in the same way it did the
> very day after it was first released.

If you want to know what to know what to put in sources.list, here's
what's in mine...

deb http://ftp.debian.org/debian/ buster main
#deb-src http://ftp.debian.org/debian/ buster main

deb http://security.debian.org/ buster/updates main
#deb-src http://security.debian.org/ buster/updates main

-- 
Tixy

Re: Definitive instructions for Buster LTS security updates

[Tixy]

On Mon, 2022-02-21 at 08:16 -0700, Keith Christian wrote:
> The Buster machine I'm planning to re-activate is still powered off
> until I find the exact security update lines for sources.list.

These won't have changed since you first installed Buster. As I said in
my other reply, Buster isn't yet in Long Term Support, it's still
getting updates from Debian's security team in the same way it did the
very day after it was first released.

-- 
Tixy

Re: Definitive instructions for Buster LTS security updates

[Chuck Zmudzinski]

On 2/21/2022 10:28 AM, Christian Britz wrote:


On 2022-02-21 15:45 UTC+0100, David Wright wrote:


AFAICT, running buster, nothing has yet changed. My sources.list
is attached (ignore the first line), and as of this morning it
yields:

And I think nothing will change in the future. Take the Stretch example
at https://wiki.debian.org/LTS/Using. The sources.list stayed the same.
Maybe buster-updates will disappear, I do not know how this is handled.

IMO it makes totally sense to leave this unchanged - every system will
automatically benefit from LTS.



I also experienced the same behavior with Jessie and now with Stretch.
I did not need to change anything in sources.list, and I received the
LTS updates for Jessie and I still receive them for Stretch while it is 
still

getting LTS updates. So I would expect buster to also not need any changes
to sources.list to receive LTS updates.

Regards,

Chuck Zmudzinski

Re: Definitive instructions for Buster LTS security updates

[Christian Britz]

On 2022-02-21 15:45 UTC+0100, David Wright wrote:

> AFAICT, running buster, nothing has yet changed. My sources.list
> is attached (ignore the first line), and as of this morning it
> yields:
And I think nothing will change in the future. Take the Stretch example
at https://wiki.debian.org/LTS/Using. The sources.list stayed the same.
Maybe buster-updates will disappear, I do not know how this is handled.

IMO it makes totally sense to leave this unchanged - every system will
automatically benefit from LTS.

-- 
http://www.cb-fraggle.de

Re: Definitive instructions for Buster LTS security updates

[Keith Christian]

On Mon, Feb 21, 2022 at 6:31 AM Greg Wooledge  wrote:
>
> On Mon, Feb 21, 2022 at 06:25:35AM -0700, Keith Christian wrote:
> > My first search brought me to wiki.debian.org, where I landed on the
> > /LTS/Using page, but it contained no Buster-specific instructions.
>
> See also  which says:
>
> Q) Where do I get buster packages?
> Use the following sources for buster:
>
> deb http://deb.debian.org/debian/ buster main
> deb http://security.debian.org/debian-security buster/updates main
>
> > E: The repository 'http://deb.debian.org/debian buster/updates
> > Release' does not have a Release file.
>
> You've got an error here.  Either you meant this to be a security line,
> and you've forgotten to use "debian-security" at the tail end of the
> URL field, or else you meant this to be a "buster-updates" line, and
> accidentally used a / instead of a - character in the third field.
>
> (I'm not sure if a  buster-updates repository section still exists for
> that release, but if it does, it'll be spelled with a hyphen.)
>


Thanks Greg,
The Buster machine I'm planning to re-activate is still powered off
until I find the exact security update lines for sources.list.
This error that you mention below is an example from my "pre-startup
research," showing a user's report.
When I find the correct sources.list lines I'll verify them with your
suggestions below.

> > E: The repository 'http://deb.debian.org/debian buster/updates
> > Release' does not have a Release file.
>
> You've got an error here.  Either you meant this to be a security line,
> and you've forgotten to use "debian-security" at the tail end of the
> URL field, or else you meant this to be a "buster-updates" line, and
> accidentally used a / instead of a - character in the third field.

Keith

Re: Definitive instructions for Buster LTS security updates

[David Wright]

On Mon 21 Feb 2022 at 08:30:54 (-0500), Greg Wooledge wrote:
> On Mon, Feb 21, 2022 at 06:25:35AM -0700, Keith Christian wrote:
> > My first search brought me to wiki.debian.org, where I landed on the
> > /LTS/Using page, but it contained no Buster-specific instructions.
> 
> See also  which says:
> 
> Q) Where do I get buster packages?
> Use the following sources for buster:
> 
> deb http://deb.debian.org/debian/ buster main
> deb http://security.debian.org/debian-security buster/updates main
> 
> > E: The repository 'http://deb.debian.org/debian buster/updates
> > Release' does not have a Release file.
> 
> You've got an error here.  Either you meant this to be a security line,
> and you've forgotten to use "debian-security" at the tail end of the
> URL field, or else you meant this to be a "buster-updates" line, and
> accidentally used a / instead of a - character in the third field.
> 
> (I'm not sure if a  buster-updates repository section still exists for
> that release, but if it does, it'll be spelled with a hyphen.)

AFAICT, running buster, nothing has yet changed. My sources.list
is attached (ignore the first line), and as of this morning it
yields:

 Feb 21 02:17 deb.debian.org_debian_dists_buster-updates_InRelease
 Jan 24 14:34 
deb.debian.org_debian_dists_buster-updates_main_Contents-amd64.diff_Index
 Jan 24 14:34 deb.debian.org_debian_dists_buster-updates_main_Contents-amd64.lz4
 Jan 24 14:34 
deb.debian.org_debian_dists_buster-updates_main_binary-amd64_Packages
 Jan 24 14:34 
deb.debian.org_debian_dists_buster-updates_main_binary-amd64_Packages.diff_Index
 Jan 24 14:34 
deb.debian.org_debian_dists_buster-updates_main_i18n_Translation-en
 Jan 24 14:34 
deb.debian.org_debian_dists_buster-updates_main_i18n_Translation-en.diff_Index
 Jan 24 14:34 deb.debian.org_debian_dists_buster-updates_main_source_Sources
 Jan 24 14:34 
deb.debian.org_debian_dists_buster-updates_main_source_Sources.diff_Index
 Oct  9 05:55 deb.debian.org_debian_dists_buster_InRelease
 Feb  6  2021 deb.debian.org_debian_dists_buster_contrib_Contents-amd64.lz4
 Oct  9 05:19 deb.debian.org_debian_dists_buster_contrib_binary-amd64_Packages
 Feb  6  2021 deb.debian.org_debian_dists_buster_contrib_i18n_Translation-en
 Oct  9 05:19 deb.debian.org_debian_dists_buster_contrib_source_Sources
 Oct  9 05:22 deb.debian.org_debian_dists_buster_main_Contents-amd64.lz4
 Oct  9 05:19 deb.debian.org_debian_dists_buster_main_binary-amd64_Packages
 Oct  9 05:19 deb.debian.org_debian_dists_buster_main_i18n_Translation-en
 Oct  9 05:19 deb.debian.org_debian_dists_buster_main_source_Sources
 Oct  9 05:20 deb.debian.org_debian_dists_buster_non-free_Contents-amd64.lz4
 Oct  9 05:19 deb.debian.org_debian_dists_buster_non-free_binary-amd64_Packages
 Oct  9 05:19 deb.debian.org_debian_dists_buster_non-free_i18n_Translation-en
 Oct  9 05:19 deb.debian.org_debian_dists_buster_non-free_source_Sources
 Feb 20 06:12 security.debian.org_debian-security_dists_buster_updates_InRelease
 Feb 19 13:44 
security.debian.org_debian-security_dists_buster_updates_main_binary-amd64_Packages
 Feb 18 12:55 
security.debian.org_debian-security_dists_buster_updates_main_i18n_Translation-en
 Feb 19 21:32 
security.debian.org_debian-security_dists_buster_updates_main_source_Sources
 Jun 26  2021 
security.debian.org_debian-security_dists_buster_updates_non-free_binary-amd64_Packages
 Nov 13  2019 
security.debian.org_debian-security_dists_buster_updates_non-free_i18n_Translation-en
 Jun 26  2021 
security.debian.org_debian-security_dists_buster_updates_non-free_source_Sources

(Contents files courtesy of apt-file, I assume.)

Cheers,
David.
# buster

# deb cdrom:[Debian GNU/Linux 10.0.0 _Buster_ - Official amd64 NETINST 
20190706-10:23]/ buster contrib main non-free

#deb cdrom:[Debian GNU/Linux 10.0.0 _Buster_ - Official amd64 NETINST 
20190706-10:23]/ buster contrib main non-free

deb http://deb.debian.org/debian/ buster main non-free contrib
deb-src http://deb.debian.org/debian/ buster main non-free contrib

deb http://security.debian.org/debian-security buster/updates main contrib 
non-free
deb-src http://security.debian.org/debian-security buster/updates main contrib 
non-free

# buster-updates, previously known as 'volatile'
deb http://deb.debian.org/debian/ buster-updates main contrib non-free
deb-src http://deb.debian.org/debian/ buster-updates main contrib non-free

# This system was installed using small removable media
# (e.g. netinst, live or single CD). The matching "deb cdrom"
# entries were disabled at the end of the installation process.
# For information about how to configure apt package sources,
# see the sources.list(5) manual.

Re: Definitive instructions for Buster LTS security updates

[Tixy]

On Mon, 2022-02-21 at 06:25 -0700, Keith Christian wrote:
> I plan to bring a Buster machine which has been shut down for quite a
> while online again.
> Before connecting it to the internet, I looked for instructions on how
> to add the LTS security updates entries to sources.list.
> 
> My first search brought me to wiki.debian.org, where I landed on the
> /LTS/Using page, but it contained no Buster-specific instructions.

I assume because Buster isn't in Long Term Support yet, it's still in
normal support by the security team. From the schedule on the wiki,
it's due to go into LTS this July.

-- 
Tixy

Re: Definitive instructions for Buster LTS security updates

[Greg Wooledge]

On Mon, Feb 21, 2022 at 06:25:35AM -0700, Keith Christian wrote:
> My first search brought me to wiki.debian.org, where I landed on the
> /LTS/Using page, but it contained no Buster-specific instructions.

See also  which says:

Q) Where do I get buster packages?
Use the following sources for buster:

deb http://deb.debian.org/debian/ buster main
deb http://security.debian.org/debian-security buster/updates main

> E: The repository 'http://deb.debian.org/debian buster/updates
> Release' does not have a Release file.

You've got an error here.  Either you meant this to be a security line,
and you've forgotten to use "debian-security" at the tail end of the
URL field, or else you meant this to be a "buster-updates" line, and
accidentally used a / instead of a - character in the third field.

(I'm not sure if a  buster-updates repository section still exists for
that release, but if it does, it'll be spelled with a hyphen.)

Definitive instructions for Buster LTS security updates

[Keith Christian]

I plan to bring a Buster machine which has been shut down for quite a
while online again.
Before connecting it to the internet, I looked for instructions on how
to add the LTS security updates entries to sources.list.

My first search brought me to wiki.debian.org, where I landed on the
/LTS/Using page, but it contained no Buster-specific instructions.

After more searches, I saw numerous posts containing messages like
these, and I decided to double check the procedure to obtain LTS
updates.

E: The repository 'http://deb.debian.org/debian buster/updates
Release' does not have a Release file.
N: Updating from such a repository can't be done securely, and is
therefore disabled by default.
N: See apt-secure(8) manpage for repository creation and user
configuration details.

Seeing the above, I decided to ask here for the latest info.

Thanks!

Re: Chromium security updates

[Nicholas Geovanis]

On Fri, Jan 28, 2022, 12:57 PM Richmond  wrote:

> Richmond  writes:
>
> > Now trying:
> >
> > gn gen out/Default "--args=is_debug=false symbol_level=0
> > blink_symbol_level=0 v8_symbol_level=0 is_official_build=true
> > chrome_pgo_phase = 0"
> >
>
> I've built this version and it is working well.
>
> As the problem with chromium is caused by the debian build tools,
> perhaps it can be provided from the stable version build as an appimage?
>
> Or perhaps it can be built without the build tools and just provided for
> selected architecture?
>

Thanks for your work.
Can you explain briefly the meaning of these 2 build parameters?:
v8_symbol_level, chrome_pgo_phase

Re: Chromium security updates

[Richmond]

Richmond  writes:

> Now trying:
>
> gn gen out/Default "--args=is_debug=false symbol_level=0
> blink_symbol_level=0 v8_symbol_level=0 is_official_build=true
> chrome_pgo_phase = 0"
>

I've built this version and it is working well.

As the problem with chromium is caused by the debian build tools,
perhaps it can be provided from the stable version build as an appimage?

Or perhaps it can be built without the build tools and just provided for
selected architecture?

Re: Chromium security updates

[Richmond]

Christian Britz  writes:

> On 2022-01-24 12:44 UTC+0100, Richmond wrote:
>
>>> I've built Version 100.0.4845.0 (Developer Build) (64-bit) and it seems
>>> to be working fine here on debian 10.
>> 
>> Not OK actually, it is very slow.
>
> The reason are probably enabled debug options.
>
> Personally I am not satisfied with the security support for any browser
> included in Debian, I just use original Firefox and Chrome (and
> Thunderbird), which are easy to install. If you don't like/trust Google
> but want to use a Chromium based browser, you might consider using
> ungoogled-chromium.

I used:

gn gen out/Default "--args=is_debug=false symbol_level=0 blink_symbol_level=0 
v8_symbol_level=0"

But it seems slow on tweetdeck with high cpu usage.

Re: Chromium security updates

[Christian Britz]

On 2022-01-24 12:44 UTC+0100, Richmond wrote:

>> I've built Version 100.0.4845.0 (Developer Build) (64-bit) and it seems
>> to be working fine here on debian 10.
> 
> Not OK actually, it is very slow.

The reason are probably enabled debug options.

Personally I am not satisfied with the security support for any browser
included in Debian, I just use original Firefox and Chrome (and
Thunderbird), which are easy to install. If you don't like/trust Google
but want to use a Chromium based browser, you might consider using
ungoogled-chromium.

Re: Chromium security updates

[Richmond]

Richmond  writes:

> Salvatore Bonaccorso  writes:
>
>> Hi,
>>
>> On Fri, Jan 21, 2022 at 07:20:26PM +0100, Andrei POPESCU wrote:
>>> On Jo, 20 ian 22, 00:08:52, Richmond wrote:
>>> > I see debian 10's chromium is currently on version 90.0.4430.212
>>> > (Developer Build), whereas google-chrome is on Version 97.0.4692.99
>>> > (Official Build) (64-bit). Does that mean it is out of date and has
>>> > security vulnerabilities?
>>> > 
>>> > https://chromereleases.googleblog.com/search/label/Stable%20updates
>>> 
>>> The plan was:
>>> 
>>> https://www.debian.org/releases/buster/amd64/release-notes/ch-information.en.html#browser-security
>>> 
>>> Unfortunately both Firefox and Chromium proved to be much more of a 
>>> challenge then expected at the time of releasing Debian 10 "buster" (now 
>>> oldstable).
>>> 
>>> Firefox appears to be in slightly better shape (updated version 
>>> available in bullseye/stable, still pending for buster/oldstable).
>>
>> In fact support for chromium in oldstable has been discontinued, see
>> https://lists.debian.org/debian-security-announce/2022/msg00012.html . 
>>
>> Regards,
>> Salvatore
>
> I've built Version 100.0.4845.0 (Developer Build) (64-bit) and it seems
> to be working fine here on debian 10.

Not OK actually, it is very slow.

Re: Chromium security updates

[Richmond]

Salvatore Bonaccorso  writes:

> Hi,
>
> On Fri, Jan 21, 2022 at 07:20:26PM +0100, Andrei POPESCU wrote:
>> On Jo, 20 ian 22, 00:08:52, Richmond wrote:
>> > I see debian 10's chromium is currently on version 90.0.4430.212
>> > (Developer Build), whereas google-chrome is on Version 97.0.4692.99
>> > (Official Build) (64-bit). Does that mean it is out of date and has
>> > security vulnerabilities?
>> > 
>> > https://chromereleases.googleblog.com/search/label/Stable%20updates
>> 
>> The plan was:
>> 
>> https://www.debian.org/releases/buster/amd64/release-notes/ch-information.en.html#browser-security
>> 
>> Unfortunately both Firefox and Chromium proved to be much more of a 
>> challenge then expected at the time of releasing Debian 10 "buster" (now 
>> oldstable).
>> 
>> Firefox appears to be in slightly better shape (updated version 
>> available in bullseye/stable, still pending for buster/oldstable).
>
> In fact support for chromium in oldstable has been discontinued, see
> https://lists.debian.org/debian-security-announce/2022/msg00012.html . 
>
> Regards,
> Salvatore

I've built Version 100.0.4845.0 (Developer Build) (64-bit) and it seems
to be working fine here on debian 10.

Re: Chromium security updates

[Salvatore Bonaccorso]

Hi,

On Fri, Jan 21, 2022 at 07:20:26PM +0100, Andrei POPESCU wrote:
> On Jo, 20 ian 22, 00:08:52, Richmond wrote:
> > I see debian 10's chromium is currently on version 90.0.4430.212
> > (Developer Build), whereas google-chrome is on Version 97.0.4692.99
> > (Official Build) (64-bit). Does that mean it is out of date and has
> > security vulnerabilities?
> > 
> > https://chromereleases.googleblog.com/search/label/Stable%20updates
> 
> The plan was:
> 
> https://www.debian.org/releases/buster/amd64/release-notes/ch-information.en.html#browser-security
> 
> Unfortunately both Firefox and Chromium proved to be much more of a 
> challenge then expected at the time of releasing Debian 10 "buster" (now 
> oldstable).
> 
> Firefox appears to be in slightly better shape (updated version 
> available in bullseye/stable, still pending for buster/oldstable).

In fact support for chromium in oldstable has been discontinued, see
https://lists.debian.org/debian-security-announce/2022/msg00012.html . 

Regards,
Salvatore

Re: Chromium security updates

[Andrei POPESCU]

On Jo, 20 ian 22, 00:08:52, Richmond wrote:
> I see debian 10's chromium is currently on version 90.0.4430.212
> (Developer Build), whereas google-chrome is on Version 97.0.4692.99
> (Official Build) (64-bit). Does that mean it is out of date and has
> security vulnerabilities?
> 
> https://chromereleases.googleblog.com/search/label/Stable%20updates

The plan was:

https://www.debian.org/releases/buster/amd64/release-notes/ch-information.en.html#browser-security

Unfortunately both Firefox and Chromium proved to be much more of a 
challenge then expected at the time of releasing Debian 10 "buster" (now 
oldstable).

Firefox appears to be in slightly better shape (updated version 
available in bullseye/stable, still pending for buster/oldstable).

Updated Chromium for bullseye/stable appears to be imminent, hopefully 
buster/oldstable will follow.
 
> Debian 10 is supported until 2024.
>
> https://wiki.debian.org/LTS

As per https://wiki.debian.org/LTS/Using not all packages are supported 
by LTS.


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


signature.asc
Description: PGP signature

Re: Chromium security updates

[Richmond]

The Wanderer  writes:

> On 2022-01-19 at 19:08, Richmond wrote:
>
>> I see debian 10's chromium is currently on version 90.0.4430.212 
>> (Developer Build), whereas google-chrome is on Version 97.0.4692.99 
>> (Official Build) (64-bit). Does that mean it is out of date and has 
>> security vulnerabilities?
>
> Roughly speaking, yes, but there's background and context here.
>
> First up: the version of Chromium in Debian stable, like that of every
> other package in stable, will remain unchanged until such a time as a
> new Debian point release is made. However, there may be updated versions
> made available in stable-backports in the meantime. (I do not use
> stable-backports myself, so anyone who knows better than I do may feel
> free to clarify, amplify, or correct on this.)
>
> Recent-ish-ly, there was discussion about dropping Chromium from Debian
> entirely (except for the version in stable, which would remain unchanged
> and quickly become stale), because the packagers couldn't keep up with
> updating the packaged version against the upstream releases, and as such
> vulnerable versions were being shipped for too long anyway. If I recall
> correctly and my archives are accurate, the chromium package actually
> *was* dropped from Debian testing at that point, with the most recent
> release before the drop having been 93.0.4577.82.
>
> I followed parts of that discussion, and from what I can tell, the
> outcome of it was that more people stepped forward and took up
> maintenance of the Debian packages for Chromium. Version 97.0.4692.71 is
> now in Debian testing, and I understand that a stable-backports build
> was pending, as of the last word in the part of the discussion I was
> following (about a week ago now); that version, or a successor, should
> make it into an updated version of Debian stable at some point.
>
> That may not help very much for now, but it should give hope for the
> future on this front, as well as bring relief that at least things
> aren't going to be ending up getting that much worse.

Thanks. I have belatedly discovered the wiki
https://wiki.debian.org/Chromium which suggests
https://wiki.debian.org/ungoogled-chromium which is also out of date. :)

Re: Chromium security updates

[The Wanderer]

On 2022-01-19 at 19:08, Richmond wrote:

> I see debian 10's chromium is currently on version 90.0.4430.212 
> (Developer Build), whereas google-chrome is on Version 97.0.4692.99 
> (Official Build) (64-bit). Does that mean it is out of date and has 
> security vulnerabilities?

Roughly speaking, yes, but there's background and context here.

First up: the version of Chromium in Debian stable, like that of every
other package in stable, will remain unchanged until such a time as a
new Debian point release is made. However, there may be updated versions
made available in stable-backports in the meantime. (I do not use
stable-backports myself, so anyone who knows better than I do may feel
free to clarify, amplify, or correct on this.)

Recent-ish-ly, there was discussion about dropping Chromium from Debian
entirely (except for the version in stable, which would remain unchanged
and quickly become stale), because the packagers couldn't keep up with
updating the packaged version against the upstream releases, and as such
vulnerable versions were being shipped for too long anyway. If I recall
correctly and my archives are accurate, the chromium package actually
*was* dropped from Debian testing at that point, with the most recent
release before the drop having been 93.0.4577.82.

I followed parts of that discussion, and from what I can tell, the
outcome of it was that more people stepped forward and took up
maintenance of the Debian packages for Chromium. Version 97.0.4692.71 is
now in Debian testing, and I understand that a stable-backports build
was pending, as of the last word in the part of the discussion I was
following (about a week ago now); that version, or a successor, should
make it into an updated version of Debian stable at some point.

That may not help very much for now, but it should give hope for the
future on this front, as well as bring relief that at least things
aren't going to be ending up getting that much worse.

-- 
   The Wanderer

The reasonable man adapts himself to the world; the unreasonable one
persists in trying to adapt the world to himself. Therefore all
progress depends on the unreasonable man. -- George Bernard Shaw



signature.asc
Description: OpenPGP digital signature

Re: Chromium security updates

[harryweaver]

20 Jan 2022, 10:08 by richm...@criptext.com:

> I see debian 10's chromium is currently on version 90.0.4430.212
> (Developer Build), whereas google-chrome is on Version 97.0.4692.99
> (Official Build) (64-bit). Does that mean it is out of date and has
> security vulnerabilities?
>
> https://chromereleases.googleblog.com/search/label/Stable%20updates
>
> Debian 10 is supported until 2024.
>
> https://wiki.debian.org/LTS
>

Aside from the usual disassociation of version numbers, I'm possessed of a 
quiet confidence that the `giving back' factor would have some lack of alacrity 
to it, once the party concerned has what it wants.
Yes.
Colour me cynical.Cheers!

Harry

Chromium security updates

[Richmond]

I see debian 10's chromium is currently on version 90.0.4430.212
(Developer Build), whereas google-chrome is on Version 97.0.4692.99
(Official Build) (64-bit). Does that mean it is out of date and has
security vulnerabilities?

https://chromereleases.googleblog.com/search/label/Stable%20updates

Debian 10 is supported until 2024.

https://wiki.debian.org/LTS

Re: APT Sources.list Line Format for Security Updates

[Gregory McPherran]

Hi Andy, I've already been using 11 (Bullseye) for months. My question was 
specific and related to documentation discrepancy regarding sources.list . I 
have been provided satisfactory answers regarding that and am all set.

Greg McPherran


From: Andrew M.A. Cater 
Sent: Tuesday, July 13, 2021 6:22 AM
To: debian-user@lists.debian.org 
Subject: Re: APT Sources.list Line Format for Security Updates

On Mon, Jul 12, 2021 at 06:55:30PM +, Gregory McPherran wrote:
> Hi,
>
> This shows the new security line form as:
> DebianBullseye - Debian 
> Wiki<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwiki.debian.org%2FDebianBullseye%3Fhighlight%3D%2528CategoryRelease%2529%23New_Featuresdata=04%7C01%7C%7Ce3d26d11ad0748715b3608d945e825d6%7C84df9e7fe9f640afb435%7C1%7C0%7C637617685625810937%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=SFTH3eR%2F%2BLwbAt4hr2%2BElfPrgfyd%2BMSi%2FGBjwjnncYI%3Dreserved=0>
> deb  
> https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fsecurity.debian.org%2Fdebian-securitydata=04%7C01%7C%7Ce3d26d11ad0748715b3608d945e825d6%7C84df9e7fe9f640afb435%7C1%7C0%7C637617685625820895%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=psaVL5ThDddY38whq6Bq%2Bah51Qf2eMKp%2BNdvz0alAJE%3Dreserved=0
>bullseye-securitymain
>
> This shows the new security line form as:
> sources.list(5) — apt — Debian unstable — Debian 
> Manpages<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmanpages.debian.org%2Funstable%2Fapt%2Fsources.list.5.en.html%23EXAMPLESdata=04%7C01%7C%7Ce3d26d11ad0748715b3608d945e825d6%7C84df9e7fe9f640afb435%7C1%7C0%7C637617685625820895%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=lN5yHj9UiBr1T%2BPeJJLUXrlSD6OMeWjuLrWHhJnbw1U%3Dreserved=0>
> deb  
> https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fsecurity.debian.org%2Fdata=04%7C01%7C%7Ce3d26d11ad0748715b3608d945e825d6%7C84df9e7fe9f640afb435%7C1%7C0%7C637617685625820895%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=wNI3mPgA%2F88EARmq6lLoRpG4qaza92gpygscbtMu6MM%3Dreserved=0
>  bullseye-securitymain
>
> Is one of
> "https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fsecurity.debian.org%2Fdebian-securitydata=04%7C01%7C%7Ce3d26d11ad0748715b3608d945e825d6%7C84df9e7fe9f640afb435%7C1%7C0%7C637617685625820895%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=psaVL5ThDddY38whq6Bq%2Bah51Qf2eMKp%2BNdvz0alAJE%3Dreserved=0;
> or   
> "https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fsecurity.debian.org%2Fdata=04%7C01%7C%7Ce3d26d11ad0748715b3608d945e825d6%7C84df9e7fe9f640afb435%7C1%7C0%7C637617685625820895%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=wNI3mPgA%2F88EARmq6lLoRpG4qaza92gpygscbtMu6MM%3Dreserved=0;
>the correct format ?
>
> Or is the "debian-security" portion optional ?
>
> Thank you,
> Greg McPherran
>

If you're still running Jessie: _please_ take the machine off the Internet
/ take it out of service to be upgraded. You're more than a year beyond all
major securiy support - unless you want to pay for ELTS.

Take the opportunity to at least upgrade to Debian 9 and, ideally, 10.
Debian 11 should be here inside a month - if you can get to 10, you'll
have at least a further year of security support for 10.

If you want detailed instructions as to how to go about this, this list
will be more than happy to oblige, I'm sure.

[Second time in 24 hours: on IRC last night I was chatting with someone in
a similar position].

Upgrading between major releases of Debian is almost always feasible and
relatively problem free. In that, we score as against some other Linux
distributions where the only option is to wipe and reinstall.

"I can't upgrade at this time" is fine for maybe a year or even two at
the outside: saying this one time after formal security support has gone
is substantially less good for you and any other users of the machine.

Andy - who is overly tweaked about keeping systems up to date and patched.

All best, as ever,

Andy Cater

Re: APT Sources.list Line Format for Security Updates

[Andrew M.A. Cater]

On Tue, Jul 13, 2021 at 08:52:18AM -0400, Michael Stone wrote:
> On Tue, Jul 13, 2021 at 10:22:17AM +, Andrew M.A. Cater wrote:
> > Take the opportunity to at least upgrade to Debian 9 and, ideally, 10.
> > Debian 11 should be here inside a month - if you can get to 10, you'll
> > have at least a further year of security support for 10.
> 
> Worth noting that skipping releases when upgrading isn't supported, so
> there's no advantage to waiting for the next one--you'll still have to
> upgrade in order.

So: havng done this - 7 - 8 - 9 on an old machine at work was not too
difficult if you take it steadily.

You face at least two changes to get it oldoldstable soon :(

Andy C

> 

Re: APT Sources.list Line Format for Security Updates

[Michael Stone]

On Tue, Jul 13, 2021 at 10:22:17AM +, Andrew M.A. Cater wrote:

Take the opportunity to at least upgrade to Debian 9 and, ideally, 10.
Debian 11 should be here inside a month - if you can get to 10, you'll
have at least a further year of security support for 10.


Worth noting that skipping releases when upgrading isn't supported, so 
there's no advantage to waiting for the next one--you'll still have to 
upgrade in order.

Re: APT Sources.list Line Format for Security Updates

[Andrew M.A. Cater]

On Mon, Jul 12, 2021 at 06:55:30PM +, Gregory McPherran wrote:
> Hi,
> 
> This shows the new security line form as:
> DebianBullseye - Debian 
> Wiki
> deb  http://security.debian.org/debian-security   bullseye-security   
>  main
> 
> This shows the new security line form as:
> sources.list(5) — apt — Debian unstable — Debian 
> Manpages
> deb  http://security.debian.org 
> bullseye-securitymain
> 
> Is one of"http://security.debian.org/debian-security;or   
> "http://security.debian.org;   the correct format ?
> 
> Or is the "debian-security" portion optional ?
> 
> Thank you,
> Greg McPherran
> 

If you're still running Jessie: _please_ take the machine off the Internet 
/ take it out of service to be upgraded. You're more than a year beyond all
major securiy support - unless you want to pay for ELTS.

Take the opportunity to at least upgrade to Debian 9 and, ideally, 10.
Debian 11 should be here inside a month - if you can get to 10, you'll 
have at least a further year of security support for 10.

If you want detailed instructions as to how to go about this, this list
will be more than happy to oblige, I'm sure.

[Second time in 24 hours: on IRC last night I was chatting with someone in
a similar position].

Upgrading between major releases of Debian is almost always feasible and
relatively problem free. In that, we score as against some other Linux
distributions where the only option is to wipe and reinstall.

"I can't upgrade at this time" is fine for maybe a year or even two at
the outside: saying this one time after formal security support has gone
is substantially less good for you and any other users of the machine.

Andy - who is overly tweaked about keeping systems up to date and patched.

All best, as ever,

Andy Cater

Re: APT Sources.list Line Format for Security Updates

[Andrei POPESCU]

On Lu, 12 iul 21, 18:55:30, Gregory McPherran wrote:
> Hi,
> 
> This shows the new security line form as:
> DebianBullseye - Debian 
> Wiki
> deb  http://security.debian.org/debian-security   bullseye-security   
>  main
> 
> This shows the new security line form as:
> sources.list(5) — apt — Debian unstable — Debian 
> Manpages
> deb  http://security.debian.org 
> bullseye-securitymain
> 
> Is one of"http://security.debian.org/debian-security;or   
> "http://security.debian.org;   the correct format ?

APT repositories are real URLs that you can open in a browser, the first 
part should work as is.

If you want to open the full path in a browser remember to add '/dists/' 
between the URL and the distribution (in this case 'bullseye-security') 
and an additional '/' for the component (in this case 'main'), like 
this:

http://security.debian.org/debian-security/dists/bullseye-security/main


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


signature.asc
Description: PGP signature

Re: APT Sources.list Line Format for Security Updates

[Brian Thompson]

On Mon, Jul 12, 2021 at 06:55:30PM +, Gregory McPherran wrote:
>Is one of"http://security.debian.org/debian-security;or   
>"http://security.debian.org;   the correct format ?
>
>Or is the "debian-security" portion optional ?

I don't think `debian-security` in the URL suffix is optional.  Use the
former instead of the latter and set the suite to `bullseye-security` as
well.
-- 
Best regards,

Brian T

Coronavirus is a scam.
9/11 was an inside job.


signature.asc
Description: PGP signature

APT Sources.list Line Format for Security Updates - Documentation Discrepancy

[Gregory McPherran]

Hi,

This shows the new security line form as:
DebianBullseye - Debian 
Wiki<https://wiki.debian.org/DebianBullseye?highlight=%28CategoryRelease%29#New_Features>
deb  http://security.debian.org/debian-security   bullseye-security 
   main

This shows the new security line form as:
sources.list(5) — apt — Debian unstable — Debian 
Manpages<https://manpages.debian.org/unstable/apt/sources.list.5.en.html#EXAMPLES>
deb  http://security.debian.org 
bullseye-securitymain

Is one of"http://security.debian.org/debian-security;or   
"http://security.debian.org<http://security.debian.org/>"   the correct format ?

Or is the "debian-security" portion optional ?

Thank you,
Greg McPherran



From: Gregory McPherran 
Sent: Monday, July 12, 2021 2:55 PM
To: debian-user@lists.debian.org 
Subject: APT Sources.list Line Format for Security Updates

Hi,

This shows the new security line form as:
DebianBullseye - Debian 
Wiki<https://wiki.debian.org/DebianBullseye?highlight=%28CategoryRelease%29#New_Features>
deb  http://security.debian.org/debian-security   bullseye-security 
   main

This shows the new security line form as:
sources.list(5) — apt — Debian unstable — Debian 
Manpages<https://manpages.debian.org/unstable/apt/sources.list.5.en.html#EXAMPLES>
deb  http://security.debian.org 
bullseye-securitymain

Is one of"http://security.debian.org/debian-security;or   
"http://security.debian.org;   the correct format ?

Or is the "debian-security" portion optional ?

Thank you,
Greg McPherran

Re: APT Sources.list Line Format for Security Updates

[Michael Stone]

On Mon, Jul 12, 2021 at 04:32:52PM -0400, Greg Wooledge wrote:

Try both and see which one works.  If the wiki is wrong, edit the wiki so
that it's correct.  (Then hope some jerk doesn't revert your changes.)


There's only one person acting like a jerk here.

Re: APT Sources.list Line Format for Security Updates

[Dan Ritter]

Greg Wooledge wrote: 
> On Mon, Jul 12, 2021 at 06:55:30PM +, Gregory McPherran wrote:
> > This shows the new security line form as:
> > DebianBullseye - Debian 
> > Wiki
> > deb  http://security.debian.org/debian-security   bullseye-security 
> >main
> > 
> > This shows the new security line form as:
> > sources.list(5) — apt — Debian unstable — Debian 
> > Manpages
> > deb  http://security.debian.org 
> > bullseye-securitymain
> > 
> > Is one of"http://security.debian.org/debian-security;or   
> > "http://security.debian.org;   the correct format ?
> > 
> > Or is the "debian-security" portion optional ?
> 
> Try both and see which one works.  If the wiki is wrong, edit the wiki so
> that it's correct.  (Then hope some jerk doesn't revert your changes.)
> If the man page is wrong, file a bug report and pray that the man page
> will be fixed in a post-11.0 point release.

On my test bullseye desktop:

deb http://security.debian.org/debian-security bullseye-security main

works without complaint.

-dsr-

Re: APT Sources.list Line Format for Security Updates

[Greg Wooledge]

On Mon, Jul 12, 2021 at 06:55:30PM +, Gregory McPherran wrote:
> This shows the new security line form as:
> DebianBullseye - Debian 
> Wiki
> deb  http://security.debian.org/debian-security   bullseye-security   
>  main
> 
> This shows the new security line form as:
> sources.list(5) — apt — Debian unstable — Debian 
> Manpages
> deb  http://security.debian.org 
> bullseye-securitymain
> 
> Is one of"http://security.debian.org/debian-security;or   
> "http://security.debian.org;   the correct format ?
> 
> Or is the "debian-security" portion optional ?

Try both and see which one works.  If the wiki is wrong, edit the wiki so
that it's correct.  (Then hope some jerk doesn't revert your changes.)
If the man page is wrong, file a bug report and pray that the man page
will be fixed in a post-11.0 point release.

APT Sources.list Line Format for Security Updates

[Gregory McPherran]

Hi,

This shows the new security line form as:
DebianBullseye - Debian 
Wiki
deb  http://security.debian.org/debian-security   bullseye-security 
   main

This shows the new security line form as:
sources.list(5) — apt — Debian unstable — Debian 
Manpages
deb  http://security.debian.org 
bullseye-securitymain

Is one of"http://security.debian.org/debian-security;or   
"http://security.debian.org;   the correct format ?

Or is the "debian-security" portion optional ?

Thank you,
Greg McPherran

Re: Auto install security updates only?

[Andrei POPESCU]

On Ma, 22 iun 21, 10:05:32, Dick Visser wrote:
> 
> It appears that linux-image-cloud-amd64 is the security update, but it
> depends on linux-image-4.19.0-17-cloud-amd64 which is not a security
> update.

The output of 'apt policy' for both package will show what's happening. 

My guess is they are both regular stable updates, not security updates.

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


signature.asc
Description: PGP signature

Auto install security updates only?

[Dick Visser]

Hi

I'm looking for a way to auto install security updates only.
To this end have configured unattended-upgrades like this:

Unattended-Upgrade::Origins-Pattern {
 "origin=Debian,codename=${distro_codename},label=Debian-Security";
  };
Unattended-Upgrade::Package-Blacklist {
};

While this works *most* of the time, it does not work *all* of the time.
A common issue is when a security update depends on another, new
package that is not labeled as Debian-Security.
Since a few days, this is the case again:

WARNING package linux-image-cloud-amd64 upgradable but fails to be
marked for upgrade ()

It appears that linux-image-cloud-amd64 is the security update, but it
depends on linux-image-4.19.0-17-cloud-amd64 which is not a security
update. If I add:
"origin=Debian,codename=${distro_codename},label=Debian";
to the Unattended-Upgrade::Origins-Pattern list (basically the
default), it works but then all packages get updated - which I don't
want.

On https://github.com/mvo5/unattended-upgrades#supported-options-reference
I noticed there is the Unattended-Upgrade::Package-Whitelist option.
But that means I have to know in advance which packages will be
upgraded - which I don't.

Any ideas on how one would auto install security updates including any
dependencies that are not labeled as Debian-Security?

thx!


-- 
Dick Visser
Trust & Identity Service Operations Manager
GÉANT

Re: How do I permanently disable unattended downloads of software/security updates?

[Andrei POPESCU]

On Vi, 04 iun 21, 16:24:32, Reco wrote:
>   Hi.
> 
> On Fri, Jun 04, 2021 at 07:59:31AM -0400, Greg Wooledge wrote:
> 
> > 3) Calling "systemctl disable" only works for *services*,
> 
> That not how it works, actually.
> systemctl disable can be used to disable any timer, but you have to
> specify it explicitly. I.e.
> 
> systemctl disable apt-daily.timer
> 
> Running "systemctl disable" on a service that's called by timer should
> do nothing indeed.

Agreed.

On the other hand disabling the systemd timer might not have the desired 
effect if an equivalent cron job exists as well and cron is installed 
(by default it is).

Side note: cron jobs that have an equivalent systemd timer should check 
if running under systemd and do nothing. On my system 
/etc/cron.daily/apt-compat does contain such a check, but maybe I missed 
some other cron job that might be invoked, I've lost track of what else 
was mentioned in the thread.

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


signature.asc
Description: PGP signature

Re: How do I permanently disable unattended downloads of software/security updates?

[David Wright]

On Fri 04 Jun 2021 at 12:40:26 (+0200), Stella Ashburne wrote:
> > Sent: Friday, June 04, 2021 at 6:02 PM
> > From: "Thomas D. Dean" 
> >
> > I use Ubuntu.  I removed the ubuntu desktop and installed vanilla gnome.
> > Google:
> > 'Converting Ubuntu 20.04 LTS to Vanilla Gnome3'
> 
> According to the website "The 8 Best Ubuntu Desktop Environments (20.04 Focal 
> Fossa Linux)" 
> [https://linuxconfig.org/the-8-best-ubuntu-desktop-environments-20-04-focal-fossa-linux],
>  Ubuntu 20.04 LTS comes with the default Gnome 3.36 desktop.
> >
> > After I disabled timers, I rebooted.  apt-update && apt-upgrade.  After
> > that I had one popup  that said I had upgrades pending.  The apt timer
> > was set to expire in 3 hours...
> 
> See...you'd an automatic download of updates.

Here are a few files with which you might compare your own versions
while you look for clues. This system has no DE installed and,
unusually for me, it has no cron job to update/upgrade the system.
It's been languishing for nearly a fortnight while I was on holiday,
and apt has shown no signs of stirring, even though I know from my
master system that yelp should be demanding a dist-upgrade (for
new packages).

Like you, I selected no-unattended-security-upgrades during
installation, but I may have packages that you lack (like, say,
apt-file) which will put extra lines in the configuration.

The cron job that's missing from this machine is
  # check for updated packages and provoke an email if any are in the cache
  0 */3 * * * apt-get -qq update && apt-get -qq -d upgrade && find 
/var/cache/apt/archives/ -name '*deb'
which, of course, does exactly what you're trying to avoid!
(For the guardians of Debian bandwidth: all my systems proxy off
apt-cacher-ng running on the system I'm typing on.)

Cheers,
David.
APT "";
APT::Architecture "amd64";
APT::Build-Essential "";
APT::Build-Essential:: "build-essential";
APT::Install-Recommends "1";
APT::Install-Suggests "0";
APT::Sandbox "";
APT::Sandbox::User "_apt";
APT::Authentication "";
APT::Authentication::TrustCDROM "true";
APT::NeverAutoRemove "";
APT::NeverAutoRemove:: "^firmware-linux.*";
APT::NeverAutoRemove:: "^linux-firmware$";
APT::NeverAutoRemove:: "^linux-image-[a-z0-9]*$";
APT::NeverAutoRemove:: "^linux-image-[a-z0-9]*-[a-z0-9]*$";
APT::NeverAutoRemove:: "^linux-image-4\.19\.0-14-amd64$";
APT::NeverAutoRemove:: "^linux-image-4\.19\.0-16-amd64$";
APT::NeverAutoRemove:: "^linux-headers-4\.19\.0-14-amd64$";
APT::NeverAutoRemove:: "^linux-headers-4\.19\.0-16-amd64$";
APT::NeverAutoRemove:: "^linux-image-extra-4\.19\.0-14-amd64$";
APT::NeverAutoRemove:: "^linux-image-extra-4\.19\.0-16-amd64$";
APT::NeverAutoRemove:: "^linux-modules-4\.19\.0-14-amd64$";
APT::NeverAutoRemove:: "^linux-modules-4\.19\.0-16-amd64$";
APT::NeverAutoRemove:: "^linux-modules-extra-4\.19\.0-14-amd64$";
APT::NeverAutoRemove:: "^linux-modules-extra-4\.19\.0-16-amd64$";
APT::NeverAutoRemove:: "^linux-signed-image-4\.19\.0-14-amd64$";
APT::NeverAutoRemove:: "^linux-signed-image-4\.19\.0-16-amd64$";
APT::NeverAutoRemove:: "^linux-image-unsigned-4\.19\.0-14-amd64$";
APT::NeverAutoRemove:: "^linux-image-unsigned-4\.19\.0-16-amd64$";
APT::NeverAutoRemove:: "^kfreebsd-image-4\.19\.0-14-amd64$";
APT::NeverAutoRemove:: "^kfreebsd-image-4\.19\.0-16-amd64$";
APT::NeverAutoRemove:: "^kfreebsd-headers-4\.19\.0-14-amd64$";
APT::NeverAutoRemove:: "^kfreebsd-headers-4\.19\.0-16-amd64$";
APT::NeverAutoRemove:: "^gnumach-image-4\.19\.0-14-amd64$";
APT::NeverAutoRemove:: "^gnumach-image-4\.19\.0-16-amd64$";
APT::NeverAutoRemove:: "^.*-modules-4\.19\.0-14-amd64$";
APT::NeverAutoRemove:: "^.*-modules-4\.19\.0-16-amd64$";
APT::NeverAutoRemove:: "^.*-kernel-4\.19\.0-14-amd64$";
APT::NeverAutoRemove:: "^.*-kernel-4\.19\.0-16-amd64$";
APT::NeverAutoRemove:: "^linux-backports-modules-.*-4\.19\.0-14-amd64$";
APT::NeverAutoRemove:: "^linux-backports-modules-.*-4\.19\.0-16-amd64$";
APT::NeverAutoRemove:: "^linux-modules-.*-4\.19\.0-14-amd64$";
APT::NeverAutoRemove:: "^linux-modules-.*-4\.19\.0-16-amd64$";
APT::NeverAutoRemove:: "^linux-tools-4\.19\.0-14-amd64$";
APT::NeverAutoRemove:: "^linux-tools-4\.19\.0-16-amd64$";
APT::NeverAutoRemove:: "^linux-cloud-tools-4\.19\.0-14-amd64$";
APT::NeverAutoRemove:: "^linux-cloud-tools-4\.19\.0-16-amd64$";
APT::NeverAutoRemove:: "^linux-buildinfo-4\.19\.0-14-amd64$";
APT::NeverAutoRemove:: "^linux-buildinfo-4\.19\.0-16-amd64$";
APT::NeverAutoRemove:: "^linux-source-4\.19\.0-14-amd64$";
APT::NeverAutoRemove:: "^linux-source-4\.19\.0-16-amd64$";
APT::VersionedKernelPackages "";
APT::VersionedKernelPackages:: "linux-image";
APT::VersionedKernelPackages:: "linux-headers";
APT::VersionedKernelPackages:: "linux-image-extra";
APT::VersionedKernelPackages:: "linux-modules";
APT::VersionedKernelPackages:: "linux-modules-extra";
APT::VersionedKernelPackages:: "linux-signed-image";
APT::VersionedKernelPackages:: "linux-image-unsigned";
APT::VersionedKernelPackages:: "kfreebsd-image";
APT::VersionedKernelPackages:: 

Re: How do I permanently disable unattended downloads of software/security updates?

[David Wright]

On Fri 04 Jun 2021 at 08:35:38 (-0400), Polyna-Maude Racicot-Summerside wrote:
> On 2021-06-04 7:59 a.m., Greg Wooledge wrote:
> > On Fri, Jun 04, 2021 at 02:15:24AM +0200, Stella Ashburne wrote:
> >> Output of systemctl list-timers | grep apt
> >>
> >> Thu  2021-06-03 20:29:30 GMT  9h leftThu 2021-06-03 09:18:00 GMT  1h 
> >> 17min ago apt-daily.timer  apt-daily.service
> >> Fri  2021-06-04 06:51:16 GMT  20h left   Thu 2021-06-03 09:18:00 GMT  1h 
> >> 17min ago apt-daily-upgrade.timer  apt-daily-upgrade.service
> > 
> > Yes, you posted this already.
> > 
> > The point wasn't for you to copy and paste the output here and wait
> > for someone to hand-hold you through the next step.  The point was
> > for you to read and understand the output yourself.
> > 
> > You've got these two systemd timers.  Now you have their names, and you
> > know when they last triggered, and when they will trigger in the future.
> > 
> > Given their names (and the fact of their *existence*) you can investigate
> > further and learn what they do.
> > 
> > You could also correlate the time that the timer last triggered against
> > the time that the packages were downloaded, to confirm causality.  If
> > you've waited too long, and the downloads actually occurred in a previous
> > cycle, then consider using "journalctl -u unitname" to get the full logs
> > from that unit.
> > 
> > Here are some more hints:
> > 
> > 1) You can use "systemctl cat" followed by a unit name to get a dump of
> >the "unit file" (which may not be a single file) which defines that
> >unit.
> > 
> > 2) Prior messages in this thread contain analysis of some of these
> >systemd units and the Debian tools that they call upon.
> > 
> >2a) The Debian tools that these units call have configuration files
> >which control what they do.  Documentation is sketchy, but most
> >of these tools are scripts, so you can read the scripts.  That's
> >part of the analysis that's already been done which you seem
> >to have skipped over.
> > 
> > 3) Calling "systemctl disable" only works for *services*, and all it
> >does is remove them from the list of services that get launched at
> >boot time.  It does nothing for units that are triggered by other
> >means than booting.
> > 
> > 4) Calling "systemctl mask" will completely remove *all* possibility of
> >a unit being invoked, by booting, or by socket trigger, or being
> >called by some other unit, etc.
> > 
> > 5) If journalctl isn't showing you logs from before your last reboot,
> >it's possible that you haven't enabled the persistent journal yet.
> >The persistent journal wasn't the default in Debian prior to (I think)
> >bullseye, which of course is not released yet.
> > 
> >To enable the persistent journal, see systemd-journald(8).  There is
> >a simple two-line recipe in there.
> > 
> > 6) Nobody knows what the fuck GNOME does.  If GNOME's doing something
> >that you dislike, well, uh... that's unfortunate.  But there's a
> >reason most of us don't run it.  Several reasons, in fact.
> 
> No one asked you for opinion regarding a particular desktop environment
> or if it's a good choice to run it or not. Those type of comment are at
> least useless at most unproductive.

Actually, I find candid opinions posted here about software to be useful.
Many times I have written "I don't know anything about DEs as I don't
run one", but I don't expect my opinion to carry any weight here.

> Yes there's people who know what GNOME does and how it's done, there's
> even people who look into the source code... And people who investigated
> GNOME the same way you tell this guy to investigate some actions of the
> timers...

Nobody here is censoring them. But my impression is that we don't hear
from them very often.

> GNOME is part of the Debian distribution so this type of opinionated
> answer shall not arrive. This seem as sterile discussion as talking to
> some hard head politician... And it goes nowhere...

So I guess this means that around 58000 pieces of software should be
protected from having opinions passed on them. It hasn't worked out
so well for systemd.

Someone recently argued that respect for people here had to be earned
(I'm not sure how). I'd argue rather that it's their opinions that
have to earn respect, by being evaluated in the context of their other
contributions. We can then all make our own individual judgements.

Cheers,
David.

Re: How do I permanently disable unattended downloads of software/security updates?

[Reco]

Hi.

On Fri, Jun 04, 2021 at 07:59:31AM -0400, Greg Wooledge wrote:
> On Fri, Jun 04, 2021 at 02:15:24AM +0200, Stella Ashburne wrote:
> > Output of systemctl list-timers | grep apt
> > 
> > Thu  2021-06-03 20:29:30 GMT  9h leftThu 2021-06-03 09:18:00 GMT  1h 
> > 17min ago apt-daily.timer  apt-daily.service
> > Fri  2021-06-04 06:51:16 GMT  20h left   Thu 2021-06-03 09:18:00 GMT  1h 
> > 17min ago apt-daily-upgrade.timer  apt-daily-upgrade.service
> 
> Yes, you posted this already.
> 
> The point wasn't for you to copy and paste the output here and wait
> for someone to hand-hold you through the next step.  The point was
> for you to read and understand the output yourself.

I'd like to add here that:

- apt-daily is written to respect APT::Periodic::* settings, and you
  have those unset.
- in this very thread a possibility of a custom cron job that download
  updates was excluded.
- therefore it's simply wrong to include in the result of "systemctl
  list-timers" only "apt" timers and exclude everything else, since
  your problem can lie in those excluded timers.


> 3) Calling "systemctl disable" only works for *services*,

That not how it works, actually.
systemctl disable can be used to disable any timer, but you have to
specify it explicitly. I.e.

systemctl disable apt-daily.timer

Running "systemctl disable" on a service that's called by timer should
do nothing indeed.

Reco

Re: How do I permanently disable unattended downloads of software/security updates?

[Polyna-Maude Racicot-Summerside]

Hi,

On 2021-06-04 7:59 a.m., Greg Wooledge wrote:
> On Fri, Jun 04, 2021 at 02:15:24AM +0200, Stella Ashburne wrote:
>> Output of systemctl list-timers | grep apt
>>
>> Thu  2021-06-03 20:29:30 GMT  9h leftThu 2021-06-03 09:18:00 GMT  1h 
>> 17min ago apt-daily.timer  apt-daily.service
>> Fri  2021-06-04 06:51:16 GMT  20h left   Thu 2021-06-03 09:18:00 GMT  1h 
>> 17min ago apt-daily-upgrade.timer  apt-daily-upgrade.service
> 
> Yes, you posted this already.
> 
> The point wasn't for you to copy and paste the output here and wait
> for someone to hand-hold you through the next step.  The point was
> for you to read and understand the output yourself.
> 
> You've got these two systemd timers.  Now you have their names, and you
> know when they last triggered, and when they will trigger in the future.
> 
> Given their names (and the fact of their *existence*) you can investigate
> further and learn what they do.
> 
> You could also correlate the time that the timer last triggered against
> the time that the packages were downloaded, to confirm causality.  If
> you've waited too long, and the downloads actually occurred in a previous
> cycle, then consider using "journalctl -u unitname" to get the full logs
> from that unit.
> 
> Here are some more hints:
> 
> 1) You can use "systemctl cat" followed by a unit name to get a dump of
>the "unit file" (which may not be a single file) which defines that
>unit.
> 
> 2) Prior messages in this thread contain analysis of some of these
>systemd units and the Debian tools that they call upon.
> 
>2a) The Debian tools that these units call have configuration files
>which control what they do.  Documentation is sketchy, but most
>of these tools are scripts, so you can read the scripts.  That's
>part of the analysis that's already been done which you seem
>to have skipped over.
> 
> 3) Calling "systemctl disable" only works for *services*, and all it
>does is remove them from the list of services that get launched at
>boot time.  It does nothing for units that are triggered by other
>means than booting.
> 
> 4) Calling "systemctl mask" will completely remove *all* possibility of
>a unit being invoked, by booting, or by socket trigger, or being
>called by some other unit, etc.
> 
> 5) If journalctl isn't showing you logs from before your last reboot,
>it's possible that you haven't enabled the persistent journal yet.
>The persistent journal wasn't the default in Debian prior to (I think)
>bullseye, which of course is not released yet.
> 
>To enable the persistent journal, see systemd-journald(8).  There is
>a simple two-line recipe in there.
> 
> 6) Nobody knows what the fuck GNOME does.  If GNOME's doing something
>that you dislike, well, uh... that's unfortunate.  But there's a
>reason most of us don't run it.  Several reasons, in fact.
> 

No one asked you for opinion regarding a particular desktop environment
or if it's a good choice to run it or not. Those type of comment are at
least useless at most unproductive.

Yes there's people who know what GNOME does and how it's done, there's
even people who look into the source code... And people who investigated
GNOME the same way you tell this guy to investigate some actions of the
timers...

GNOME is part of the Debian distribution so this type of opinionated
answer shall not arrive. This seem as sterile discussion as talking to
some hard head politician... And it goes nowhere...

-- 
Polyna-Maude R.-Summerside
-Be smart, Be wise, Support opensource development



OpenPGP_signature
Description: OpenPGP digital signature

Re: How do I permanently disable unattended downloads of software/security updates?

[Greg Wooledge]

On Fri, Jun 04, 2021 at 02:15:24AM +0200, Stella Ashburne wrote:
> Output of systemctl list-timers | grep apt
> 
> Thu  2021-06-03 20:29:30 GMT  9h leftThu 2021-06-03 09:18:00 GMT  1h 
> 17min ago apt-daily.timer  apt-daily.service
> Fri  2021-06-04 06:51:16 GMT  20h left   Thu 2021-06-03 09:18:00 GMT  1h 
> 17min ago apt-daily-upgrade.timer  apt-daily-upgrade.service

Yes, you posted this already.

The point wasn't for you to copy and paste the output here and wait
for someone to hand-hold you through the next step.  The point was
for you to read and understand the output yourself.

You've got these two systemd timers.  Now you have their names, and you
know when they last triggered, and when they will trigger in the future.

Given their names (and the fact of their *existence*) you can investigate
further and learn what they do.

You could also correlate the time that the timer last triggered against
the time that the packages were downloaded, to confirm causality.  If
you've waited too long, and the downloads actually occurred in a previous
cycle, then consider using "journalctl -u unitname" to get the full logs
from that unit.

Here are some more hints:

1) You can use "systemctl cat" followed by a unit name to get a dump of
   the "unit file" (which may not be a single file) which defines that
   unit.

2) Prior messages in this thread contain analysis of some of these
   systemd units and the Debian tools that they call upon.

   2a) The Debian tools that these units call have configuration files
   which control what they do.  Documentation is sketchy, but most
   of these tools are scripts, so you can read the scripts.  That's
   part of the analysis that's already been done which you seem
   to have skipped over.

3) Calling "systemctl disable" only works for *services*, and all it
   does is remove them from the list of services that get launched at
   boot time.  It does nothing for units that are triggered by other
   means than booting.

4) Calling "systemctl mask" will completely remove *all* possibility of
   a unit being invoked, by booting, or by socket trigger, or being
   called by some other unit, etc.

5) If journalctl isn't showing you logs from before your last reboot,
   it's possible that you haven't enabled the persistent journal yet.
   The persistent journal wasn't the default in Debian prior to (I think)
   bullseye, which of course is not released yet.

   To enable the persistent journal, see systemd-journald(8).  There is
   a simple two-line recipe in there.

6) Nobody knows what the fuck GNOME does.  If GNOME's doing something
   that you dislike, well, uh... that's unfortunate.  But there's a
   reason most of us don't run it.  Several reasons, in fact.

Re: How do I permanently disable unattended downloads of software/security updates?

[Stella Ashburne]

Hi Thomas

> Sent: Friday, June 04, 2021 at 6:02 PM
> From: "Thomas D. Dean" 
> To: debian-user@lists.debian.org
> Subject: Re: How do I permanently disable unattended downloads of 
> software/security updates?
>
> I use Ubuntu.  I removed the ubuntu desktop and installed vanilla gnome.
> Google:
> 'Converting Ubuntu 20.04 LTS to Vanilla Gnome3'

According to the website "The 8 Best Ubuntu Desktop Environments (20.04 Focal 
Fossa Linux)" 
[https://linuxconfig.org/the-8-best-ubuntu-desktop-environments-20-04-focal-fossa-linux],
 Ubuntu 20.04 LTS comes with the default Gnome 3.36 desktop.
>
> After I disabled timers, I rebooted.  apt-update && apt-upgrade.  After
> that I had one popup  that said I had upgrades pending.  The apt timer
> was set to expire in 3 hours...

See...you'd an automatic download of updates.

Re: How do I permanently disable unattended downloads of software/security updates?

[Thomas D. Dean]

On 6/3/21 11:15 PM, Stella Ashburne wrote:

Hi Thomas

Thank you for your help and time. I really appreciate it.


Sent: Friday, June 04, 2021 at 10:23 AM
From: "Thomas D. Dean" 
To: debian-user@lists.debian.org
Subject: Re: How do I permanently disable unattended downloads of 
software/security updates?

I have the same problem.


OK, but do you use Ubuntu or Debian or both?


I saw this in: https://askubuntu.com/questions/1038923

sudo systemctl disable apt-daily.service
sudo systemctl disable apt-daily.timer

sudo systemctl disable apt-daily-upgrade.timer
sudo systemctl disable apt-daily-upgrade.service


A poster named l0f...@tuta.io replied to me via this mailing list yesterday and 
below is what he wrote (verbatim):

"Cannot remember if you have Gnome installed but you should have a look at 
https://unix.stackexchange.com/a/594287, especially ALL the associated comments (click on 
"Show 7 more comments")."

When I did a *fresh* minimal install of Debian about two years ago, I didn't 
install the whole Gnome DE. Instead, I installed the following packages: xorg 
gnome-core gnome-tweak-tool synaptic file-roller gedit

A few days ago, after reading replies from some posters, I purged the package 
called unattended-upgrades. I don't know how and when it was installed in the 
first place. You see, about two years I chose the option Expert Install 
(without GUI) and during the installation process, I chose the option to not 
install updates automatically.

After reading what was written in the page 
(https://unix.stackexchange.com/a/594287), I disabled the package called 
PackageKit today. Only time will tell if said step works.

By the way, does Ubuntu use the full or stripped-down version of Gnome Desktop 
Environment?

*fresh* = not upgraded from Debian Stretch



I use Ubuntu.  I removed the ubuntu desktop and installed vanilla gnome. 
Google:

'Converting Ubuntu 20.04 LTS to Vanilla Gnome3'

After I disabled timers, I rebooted.  apt-update && apt-upgrade.  After 
that I had one popup  that said I had upgrades pending.  The apt timer 
was set to expire in 3 hours...

Re: How do I permanently disable unattended downloads of software/security updates?

[Andrei POPESCU]

On Vi, 04 iun 21, 02:03:10, Stella Ashburne wrote:
> Hi Tom
> 
> > Sent: Friday, June 04, 2021 at 4:18 AM
> > From: "Tom Browder" 
> 
> Don't get me wrong Tom. I'm perfectly fine with receiving emails in 
> HTML format. It's just that a few years ago, when I sent emails with 
> HTML formatting, Debian User Mailing List rejected them outright. It 
> took me quite a while - about at least two months - trying to figure 
> out why my sent HTML-formatted emails were rejected.

As far as I know the list only rejects large-ish attachments. A small 
screenshot, output of 'dmesg' or compressed logs should go through 
(though not necessarily a good idea).

> > This time i'm replying from my laptop so it **should** be plain text.
> >
> I am OK as long as Debian User Mailing List now accepts HTML-formatted 
> emails.

HTML mails are possible, just frowned upon, especially if they don't 
contain an equivalent text part (which would make the html part 
redundant). Most readers will have their mail client configured to 
display the text part (only).

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


signature.asc
Description: PGP signature

Re: How do I permanently disable unattended downloads of software/security updates?

[Stella Ashburne]

Hi Thomas

Thank you for your help and time. I really appreciate it.

> Sent: Friday, June 04, 2021 at 10:23 AM
> From: "Thomas D. Dean" 
> To: debian-user@lists.debian.org
> Subject: Re: How do I permanently disable unattended downloads of 
> software/security updates?
>
> I have the same problem.

OK, but do you use Ubuntu or Debian or both?
>
> I saw this in: https://askubuntu.com/questions/1038923
>
> sudo systemctl disable apt-daily.service
> sudo systemctl disable apt-daily.timer
>
> sudo systemctl disable apt-daily-upgrade.timer
> sudo systemctl disable apt-daily-upgrade.service
>
A poster named l0f...@tuta.io replied to me via this mailing list yesterday and 
below is what he wrote (verbatim):

"Cannot remember if you have Gnome installed but you should have a look at 
https://unix.stackexchange.com/a/594287, especially ALL the associated comments 
(click on "Show 7 more comments")."

When I did a *fresh* minimal install of Debian about two years ago, I didn't 
install the whole Gnome DE. Instead, I installed the following packages: xorg 
gnome-core gnome-tweak-tool synaptic file-roller gedit

A few days ago, after reading replies from some posters, I purged the package 
called unattended-upgrades. I don't know how and when it was installed in the 
first place. You see, about two years I chose the option Expert Install 
(without GUI) and during the installation process, I chose the option to not 
install updates automatically.

After reading what was written in the page 
(https://unix.stackexchange.com/a/594287), I disabled the package called 
PackageKit today. Only time will tell if said step works.

By the way, does Ubuntu use the full or stripped-down version of Gnome Desktop 
Environment?

*fresh* = not upgraded from Debian Stretch

Re: How do I permanently disable unattended downloads of software/security updates?

[Thomas D. Dean]

On 6/3/21 5:15 PM, Stella Ashburne wrote:

Hi Greg


Sent: Thursday, June 03, 2021 at 9:55 AM
From: "Greg Wooledge" 
To: debian-user@lists.debian.org
Subject: Re: How do I permanently disable unattended downloads of 
software/security updates?


I gave some alternatives that will reveal more information.  Replies to
my reply elaborated further still.


Output of systemctl list-timers | grep apt

Thu  2021-06-03 20:29:30 GMT  9h leftThu 2021-06-03 09:18:00 GMT  1h 17min 
ago apt-daily.timer  apt-daily.service
Fri  2021-06-04 06:51:16 GMT  20h left   Thu 2021-06-03 09:18:00 GMT  1h 17min 
ago apt-daily-upgrade.timer  apt-daily-upgrade.service



I have the same problem.

I saw this in: https://askubuntu.com/questions/1038923

sudo systemctl disable apt-daily.service
sudo systemctl disable apt-daily.timer

sudo systemctl disable apt-daily-upgrade.timer
sudo systemctl disable apt-daily-upgrade.service

Re: How do I permanently disable unattended downloads of software/security updates?

[Stella Ashburne]

Hi Greg

> Sent: Thursday, June 03, 2021 at 9:55 AM
> From: "Greg Wooledge" 
> To: debian-user@lists.debian.org
> Subject: Re: How do I permanently disable unattended downloads of 
> software/security updates?
>
>
> I gave some alternatives that will reveal more information.  Replies to
> my reply elaborated further still.
>
Output of systemctl list-timers | grep apt

Thu  2021-06-03 20:29:30 GMT  9h leftThu 2021-06-03 09:18:00 GMT  1h 17min 
ago apt-daily.timer  apt-daily.service
Fri  2021-06-04 06:51:16 GMT  20h left   Thu 2021-06-03 09:18:00 GMT  1h 17min 
ago apt-daily-upgrade.timer  apt-daily-upgrade.service

Re: How do I permanently disable unattended downloads of software/security updates?

[Stella Ashburne]

Hi Tom

> Sent: Friday, June 04, 2021 at 4:18 AM
> From: "Tom Browder" 
> To: "Stella Ashburne" 
> Cc: "debian-user mailing list" 
> Subject: Re: How do I permanently disable unattended downloads of 
> software/security updates?
>
>
> Unfortunately I mostly use email from my iPad (gmail app) and I
> haven't found a way to get plain text on it like one can from a real
> computer. Sometimes I go to my Linux laptop and force plain text, but
> normally I try to strip out what I can.
>

Don't get me wrong Tom. I'm perfectly fine with receiving emails in HTML 
format. It's just that a few years ago, when I sent emails with HTML 
formatting, Debian User Mailing List rejected them outright. It took me quite a 
while - about at least two months - trying to figure out why my sent 
HTML-formatted emails were rejected.

> This time i'm replying from my laptop so it **should** be plain text.
>
I am OK as long as Debian User Mailing List now accepts HTML-formatted emails.

Stella

Re: How do I permanently disable unattended downloads of software/security updates?

[Greg Wooledge]

On Thu, Jun 03, 2021 at 03:18:31PM -0500, Tom Browder wrote:
> This time i'm replying from my laptop so it **should** be plain text.

It is.

Re: How do I permanently disable unattended downloads of software/security updates?

[Tom Browder]

On Wed, Jun 2, 2021 at 20:48 Stella Ashburne  wrote:
...
> On a different topic, I noticed that you composed your email with HTML 
> formatting. I didn't know
> it is allowed by Debian User Mailing List.

Unfortunately I mostly use email from my iPad (gmail app) and I
haven't found a way to get plain text on it like one can from a real
computer. Sometimes I go to my Linux laptop and force plain text, but
normally I try to strip out what I can.

This time i'm replying from my laptop so it **should** be plain text.

Best,

-Tom

Re: How do I permanently disable unattended downloads of software/security updates?

[Stella Ashburne]

Hi

Thanks for your help and time. I really appreciate it.

> Sent: Thursday, June 03, 2021 at 3:03 AM
> From: "Linux-Fan" 
> To: debian-user@lists.debian.org
> Subject: Re: How do I permanently disable unattended downloads of 
> software/security updates?
>

> > Anyway, I suspect that the OP might find some useful information from
> > this command:
> >
> > systemctl list-timers | grep apt

Below is the output of systemctl list-timers | grep apt

Thu 2021-06-03 20:29:30 GMT  9h leftThu 2021-06-03 09:18:00 GMT  1h 17min 
ago apt-daily.timer  apt-daily.service
Fri 2021-06-04 06:51:16 GMT  20h left   Thu 2021-06-03 09:18:00 GMT  1h 17min 
ago apt-daily-upgrade.timer  apt-daily-upgrade.service

>
> I am leaning towards the "DE explanation" -- that the upgrades are not
> caused by APT's own mechanisms but rather triggered by some DE through
> opaque means not visible in cron or systemd timers. I am not sure how I
> would go about identifying the cause there, except for checking the GUI
> configuration that all related options are turned off?
>
One of the posters provided me a link to the post in Unix StackExchange: 
https://unix.stackexchange.com/a/594287 and I have followed the instructions to 
disable PackageKit.

By the way, when I did a fresh minimal install of Debian Buster without 
installing the full Gnome DE about two years ago, I also installed the 
following packages: xorg gnome-core gnome-tweak-tool synaptic gedit gdebi 
file-roller

Re: How do I permanently disable unattended downloads of software/security updates?

[Stella Ashburne]

Hi,

Thanks for your help and effort. I really appreciate it.

> Sent: Thursday, June 03, 2021 at 4:02 AM
> From: l0f...@tuta.io
> To: "Debian User" 
> Subject: Re: How do I permanently disable unattended downloads of 
> software/security updates?
>
> Cannot remember if you have Gnome installed but you should have a look at 
> https://unix.stackexchange.com/a/594287, especially ALL the associated 
> comments (click on "Show 7 more comments").

After I have done a fresh minimal install of Debian, I installed the following 
packages:

xorg gnome-core gnome-tweak-tool synaptic gedit gdebi file-roller

As you can see from the above, I did not install the full Gnome desktop 
environment.

The link that you gave me leads to the post in which the description of the 
problem is similar to my issue. It contains helpful information and I have 
taken action based on what the contributors had written. I have disabled 
PackageKit. I have not purged gnome-software as advised by the contributor in 
said post. Why? I am afraid that purging gnome-software may cause my operating 
system to become unusable.

I shall keep you informed if after disabling PackageKit, automatic downloads of 
software/security updates still take place.

Re: How do I permanently disable unattended downloads of software/security updates?

[Greg Wooledge]

On Thu, Jun 03, 2021 at 03:54:01AM +0200, Stella Ashburne wrote:
> > From: "Reco" 

> > The most important parts of "systemctl list-timers" (your problem
> > considered) are UNIT and ACTIVATES columns, and your result lacks them
> > for some reason.
> >
> What does "your result lacks them for some reason" mean? Could you elaborate 
> it please?

Lacks means "does not have".

Your output did not show the UNIT or ACTIVATES columns.  For the reasons
I explained in my response.

I gave some alternatives that will reveal more information.  Replies to
my reply elaborated further still.

Re: How do I permanently disable unattended downloads of software/security updates?

[Stella Ashburne]

Hi Reco

Thanks for your help and time. I really appreciate it.

> Sent: Thursday, June 03, 2021 at 12:33 AM
> From: "Reco" 
> To: debian-user@lists.debian.org
> Subject: Re: How do I permanently disable unattended downloads of 
> software/security updates?
>
> The most important parts of "systemctl list-timers" (your problem
> considered) are UNIT and ACTIVATES columns, and your result lacks them
> for some reason.
>
What does "your result lacks them for some reason" mean? Could you elaborate it 
please?

Stella

Re: How do I permanently disable unattended downloads of software/security updates?

[Stella Ashburne]

Hi Tom

Thanks for your help and time. I really appreciate it.
 
 
Sent: Thursday, June 03, 2021 at 3:53 AM
From: "Tom Browder" 
To: "Stella Ashburne" 
Cc: debian-user@lists.debian.org
Subject: Re: How do I permanently disable unattended downloads of 
software/security updates?

 
How did you get the installation originally? Was it from a fresh install of 
Buster or an upgrade from 9 or older version?
 
-Tom

It was a fresh installation. I never do upgrades from Debian Stretch (a.k.a. 
version 9) and always choose Expert Install (without GUI).

On a different topic, I noticed that you composed your email with HTML 
formatting. I didn't know it is allowed by Debian User Mailing List. I remember 
a few years ago, if one were to send an email to said mailing list, the former 
would never be published. At that time, all emails must be in plain text 
format. When did said mailing list accept emails that are HTML formatted?

Re: How do I permanently disable unattended downloads of software/security updates?

[l0f4r0]

Stella,

Cannot remember if you have Gnome installed but you should have a look at 
https://unix.stackexchange.com/a/594287, especially ALL the associated comments 
(click on "Show 7 more comments").
HTH
l0f4r0

Re: How do I permanently disable unattended downloads of software/security updates?

[Tom Browder]

On Tue, May 25, 2021 at 12:25 Stella Ashburne  wrote:

> My OS is Debian 10.9 and has the kernel version:


How did you get the installation originally? Was it from a fresh install of
Buster or an upgrade from 9 or older version?

-Tom

Re: How do I permanently disable unattended downloads of software/security updates?

[Greg Wooledge]

On Wed, Jun 02, 2021 at 09:03:23PM +0200, Linux-Fan wrote:
>   alias systemctl='systemctl -l --no-pager'
>   alias journalctl='journalctl --no-pager'

Hmm, that's handy because it preserves the underline/boldface terminal
markup, unlike the |cat trick.

> > systemctl list-timers | grep apt
> 
> As far as I can tell, these ultimately lead to
> /usr/lib/apt/apt.systemd.daily which in turn claims to honor
> `APT::Periodic::Enable "1";` from /etc/apt/apt.conf.d.

I've just spent a few minutes reading /usr/lib/apt/apt.systemd.daily ...
it's not pretty.[1]

First thing I noticed is that in the absence of APT::Periodic::Enable
it *assumes* 1 (yes).  It does this by setting a variable to 1, and then
running the following command:

apt-config shell AutoAptEnable APT::Periodic::Enable

capturing the output, eval-ing it (without quotes!), and then checking
whether that shell variable's value is still 1.  On my system, where
there is no APT::Periodic::Enable in any part of apt's config, the
output of that apt-config command is empty.  So the eval does nothing,
and the variable remains set to 1 (yes).

The next thing I noticed is that apt-daily-upgrade.service runs the same
script with "install" as its argument.  The section of the script that
this triggers is basically a giant wrapper around unattended-upgrade.
If unattended-upgrade is not found in PATH (using a *terrible* check),
pretty much nothing happens.  Of course, it doesn't bother logging that
unless it's running in debug mode.

> # journalctl -u apt-daily-upgrade.service
> -- Logs begin at Wed 2021-06-02 12:24:45 CEST, end at Wed 2021-06-02
> 20:47:39 CEST. --
> Jun 02 12:24:55 masysma-18 systemd[1]: Starting Daily apt upgrade and clean
> activities...
> Jun 02 12:24:56 masysma-18 systemd[1]: apt-daily-upgrade.service: Succeeded.
> Jun 02 12:24:56 masysma-18 systemd[1]: Started Daily apt upgrade and clean
> activities.

Mine is similar, albeit much longer.  Note that on my system,
unattended-upgrade is not installed.

[1] Here's one example:

if which unattended-upgrade >/dev/null 2>&1 && env LC_ALL=C.UTF-8 
unattended-upgrade --help | grep -q download-only && check_stamp 
$DOWNLOAD_UPGRADEABLE_STAMP $UnattendedUpgradeInterval; then

Re: How do I permanently disable unattended downloads of software/security updates?

[Linux-Fan]

Greg Wooledge writes:


On Wed, Jun 02, 2021 at 07:33:32PM +0300, Reco wrote:
>Hi.
>
> On Wed, Jun 02, 2021 at 06:27:45PM +0200, Stella Ashburne wrote:
> > Output of systemctl list-timers


[...]


> > 6 timers listed.
> > Pass --all to see loaded but inactive timers, too.
>
> The most important parts of "systemctl list-timers" (your problem
> considered) are UNIT and ACTIVATES columns, and your result lacks them
> for some reason.

The designers of systemctl made some odd choices.  They drop you into a
weird interactive mode by default, and expect you to be willing and able
to scroll around to see the fields of this report.  Worst of all is that
you may not even *know* that you're supposed to do this.


[...]


to work, you need to redirect or pipe systemctl's output so that it isn't
going to a terminal.

systemctl list-timers | cat

Of course, this is still ugly as sin, because the designers of systemctl
don't understand that terminals are 80 characters wide, always and forever.
They just dump a bunch of longer-than-140-character lines and let them
wrap as they will.  Well, at least the information is there, even if it's
hard to read.


I have added the following aliases to all my systems:

alias systemctl='systemctl -l --no-pager'
alias journalctl='journalctl --no-pager'

But of course, I like that `cat` trick for systems which I do not own.
Much easier than remembering that it was `--no-pager` :)

[...]


Anyway, I suspect that the OP might find some useful information from
this command:

systemctl list-timers | grep apt


As far as I can tell, these ultimately lead to  
/usr/lib/apt/apt.systemd.daily which in turn claims to honor  
`APT::Periodic::Enable "1";` from /etc/apt/apt.conf.d.


Still it is worth checking the logs from the systemd timers, e.g.:

journalctl --no-pager -u apt-daily-upgrade.service
journalctl --no-pager -u apt-daily.service

It is also possible that there might be systemd user timers?

systemctl --user --no-pager -l list-timers

Here, the outputs are as follows:

~~~
# journalctl -u apt-daily-upgrade.service
-- Logs begin at Wed 2021-06-02 12:24:45 CEST, end at Wed 2021-06-02  
20:47:39 CEST. --
Jun 02 12:24:55 masysma-18 systemd[1]: Starting Daily apt upgrade and clean  
activities...

Jun 02 12:24:56 masysma-18 systemd[1]: apt-daily-upgrade.service: Succeeded.
Jun 02 12:24:56 masysma-18 systemd[1]: Started Daily apt upgrade and clean  
activities.


# journalctl -u apt-daily.service
-- Logs begin at Wed 2021-06-02 12:24:45 CEST, end at Wed 2021-06-02  
20:54:02 CEST. --
Jun 02 12:24:55 masysma-18 systemd[1]: Starting Daily apt download  
activities...

Jun 02 12:24:55 masysma-18 systemd[1]: apt-daily.service: Succeeded.
Jun 02 12:24:55 masysma-18 systemd[1]: Started Daily apt download activities.

$ systemctl --user --no-pager -l list-timers
0 timers listed.
Pass --all to see loaded but inactive timers, too.
~~~

I do not believe to have observed the automatic download behaviour the OP  
sees despite the timers obviously being active and the script running. From  
the timings (between start and completion of the `apt.systemd.daily`) it  
seems to not do anything out of the box.


I am leaning towards the "DE explanation" -- that the upgrades are not  
caused by APT's own mechanisms but rather triggered by some DE through  
opaque means not visible in cron or systemd timers. I am not sure how I  
would go about identifying the cause there, except for checking the GUI  
configuration that all related options are turned off?


HTH
Linux-Fan

öö


pgpHlpmwe63e_.pgp
Description: PGP signature

Re: How do I permanently disable unattended downloads of software/security updates?

[Greg Wooledge]

On Wed, Jun 02, 2021 at 07:33:32PM +0300, Reco wrote:
>   Hi.
> 
> On Wed, Jun 02, 2021 at 06:27:45PM +0200, Stella Ashburne wrote:
> > Output of systemctl list-timers
> > 
> > 
> > NEXT LEFT  LAST 
> > PASSED
> > Wed 2021-06-02 16:24:55 GMT  4min 34s left n/a  n/a
> > Thu 2021-06-03 00:00:00 GMT  7h left   Wed 2021-06-02 16:10:36 GMT  
> > 9min ago
> > Thu 2021-06-03 00:00:00 GMT  7h left   Wed 2021-06-02 16:10:36 GMT  
> > 9min ago
> > Thu 2021-06-03 00:39:22 GMT  8h left   Wed 2021-06-02 16:10:36 GMT  
> > 9min ago
> > Thu 2021-06-03 06:40:44 GMT  14h left  Wed 2021-06-02 07:43:04 GMT  8h 
> > ago
> > Thu 2021-06-03 07:30:43 GMT  15h left  Thu 2021-06-03 00:10:06 GMT  7h 
> > left
> > 
> > 6 timers listed.
> > Pass --all to see loaded but inactive timers, too.
> 
> The most important parts of "systemctl list-timers" (your problem
> considered) are UNIT and ACTIVATES columns, and your result lacks them
> for some reason.

The designers of systemctl made some odd choices.  They drop you into a
weird interactive mode by default, and expect you to be willing and able
to scroll around to see the fields of this report.  Worst of all is that
you may not even *know* that you're supposed to do this.

If you run "systemctl list-timers" in a terminal, you may (or may not)
notice a few things:

1) You're placed in a pager, even if the output has many fewer lines than
   your terminal does.  How can you tell you're in a pager?  There's a
   prompt at the bottom of the screen.  You may recognize it if you've
   had enough experience with reading man pages.

2) There are two tremendously wide date/time fields visible, with redundant
   day-of-week and timezone fields, but not the actually *important*
   information like what's going to happen at that time.

3) There are some reverse-video > signs on the right hand side of the report.

What you're expected to do is use the Right and Left arrow keys on your
keyboard (assuming they're correctly mapped in your terminal emulator's
terminfo entries) to scroll back and forth to see the other fields.  Which
you're supposed to guess exist.

If for some reason you would simply like to see all of the information on
the screen at once, the way a Unix user would *expect* a command like this
to work, you need to redirect or pipe systemctl's output so that it isn't
going to a terminal.

systemctl list-timers | cat

Of course, this is still ugly as sin, because the designers of systemctl
don't understand that terminals are 80 characters wide, always and forever.
They just dump a bunch of longer-than-140-character lines and let them
wrap as they will.  Well, at least the information is there, even if it's
hard to read.

Those wide timestamps are just ridiculous, aren't they?  And why isn't
the unit name (the most important thing) shown first?  Or even *at all*
by default?

Anyway, I suspect that the OP might find some useful information from
this command:

systemctl list-timers | grep apt

Re: How do I permanently disable unattended downloads of software/security updates?

[Reco]

Hi.

On Wed, Jun 02, 2021 at 06:27:45PM +0200, Stella Ashburne wrote:
> Output of systemctl list-timers
> 
> 
> NEXT LEFT  LAST PASSED
> Wed 2021-06-02 16:24:55 GMT  4min 34s left n/a  n/a
> Thu 2021-06-03 00:00:00 GMT  7h left   Wed 2021-06-02 16:10:36 GMT  9min 
> ago
> Thu 2021-06-03 00:00:00 GMT  7h left   Wed 2021-06-02 16:10:36 GMT  9min 
> ago
> Thu 2021-06-03 00:39:22 GMT  8h left   Wed 2021-06-02 16:10:36 GMT  9min 
> ago
> Thu 2021-06-03 06:40:44 GMT  14h left  Wed 2021-06-02 07:43:04 GMT  8h ago
> Thu 2021-06-03 07:30:43 GMT  15h left  Thu 2021-06-03 00:10:06 GMT  7h 
> left
> 
> 6 timers listed.
> Pass --all to see loaded but inactive timers, too.

The most important parts of "systemctl list-timers" (your problem
considered) are UNIT and ACTIVATES columns, and your result lacks them
for some reason.

Reco

Re: How do I permanently disable unattended downloads of software/security updates?

[Stella Ashburne]

Hi

Thanks for your help and time. I really appreciate it.

> Sent: Wednesday, June 02, 2021 at 7:49 PM
> From: l0f...@tuta.io
> To: "Debian User" 
> Subject: Re: How do I permanently disable unattended downloads of 
> software/security updates?
>
> What about the following commands?
>
> cat /etc/anacrontab
> systemctl list-timers
>
Output of cat /etc/anacrontab

# /etc/anacrontab: configuration file for anacron

# See anacron(8) and anacrontab(5) for details.

SHELL=/bin/sh
PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin
HOME=/root
LOGNAME=root

# These replace cron's entries
1   5   cron.daily  run-parts --report /etc/cron.daily
7   10  cron.weekly run-parts --report /etc/cron.weekly
@monthly15  cron.monthlyrun-parts --report /etc/cron.monthly


Output of systemctl list-timers


NEXT LEFT  LAST PASSED
Wed 2021-06-02 16:24:55 GMT  4min 34s left n/a  n/a
Thu 2021-06-03 00:00:00 GMT  7h left   Wed 2021-06-02 16:10:36 GMT  9min ago
Thu 2021-06-03 00:00:00 GMT  7h left   Wed 2021-06-02 16:10:36 GMT  9min ago
Thu 2021-06-03 00:39:22 GMT  8h left   Wed 2021-06-02 16:10:36 GMT  9min ago
Thu 2021-06-03 06:40:44 GMT  14h left  Wed 2021-06-02 07:43:04 GMT  8h ago
Thu 2021-06-03 07:30:43 GMT  15h left  Thu 2021-06-03 00:10:06 GMT  7h left

6 timers listed.
Pass --all to see loaded but inactive timers, too.

Re: How do I permanently disable unattended downloads of software/security updates?

[l0f4r0]

2 juin 2021, 13:03 de rewe...@gmx.com:

>> Can you provide us with the output of the following commands?
>>
> Output of crontab -l
>
> No crontab for username
>
>
> Output of sudo crontab -l
>
> No crontab for root
>
>
> Output of cat /etc/crontab
>
> # /etc/crontab: system-wide crontab
> # Unlike any other crontab you don't have to run the `crontab'
> # command to install the new version when you edit this file
> # and files in /etc/cron.d. These files also have username fields,
> # that none of the other crontabs do.
>
> SHELL=/bin/sh
> PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin
>
> # Example of job definition:
> # . minute (0 - 59)
> # |  .- hour (0 - 23)
> # |  |  .-- day of month (1 - 31)
> # |  |  |  .--- month (1 - 12) OR jan,feb,mar,apr ...
> # |  |  |  |  . day of week (0 - 6) (Sunday=0 or 7) OR 
> sun,mon,tue,wed,thu,fri,sat
> # |  |  |  |  |
> # *  *  *  *  * user-name command to be executed
> 17 *  * * *   rootcd / && run-parts --report /etc/cron.hourly
> 25 6  * * *   roottest -x /usr/sbin/anacron || ( cd / && run-parts 
> --report /etc/cron.daily )
> 47 6  * * 7   roottest -x /usr/sbin/anacron || ( cd / && run-parts 
> --report /etc/cron.weekly )
> 52 6  1 * *   roottest -x /usr/sbin/anacron || ( cd / && run-parts 
> --report /etc/cron.monthly )
> #
>
>
> Output of ls -l /etc/cron.*
>
> /etc/cron.d:
> total 4
> -rw-r--r-- 1 root root 285 May 19  2019 anacron
>
> /etc/cron.daily:
> total 32
> -rwxr-xr-x 1 root root  311 May 19  2019 0anacron
> -rwxr-xr-x 1 root root 1478 May 12  2020 apt-compat
> -rwxr-xr-x 1 root root  355 Dec 29  2017 bsdmainutils
> -rwxr-xr-x 1 root root  384 Dec 31  2018 cracklib-runtime
> -rwxr-xr-x 1 root root 1187 Apr 19  2019 dpkg
> -rwxr-xr-x 1 root root  377 Aug 28  2018 logrotate
> -rwxr-xr-x 1 root root 1123 Feb 10  2019 man-db
> -rwxr-xr-x 1 root root  249 Sep 27  2017 passwd
>
> /etc/cron.hourly:
> total 0
>
> /etc/cron.monthly:
> total 4
> -rwxr-xr-x 1 root root 313 May 19  2019 0anacron
>
> /etc/cron.weekly:
> total 8
> -rwxr-xr-x 1 root root 312 May 19  2019 0anacron
> -rwxr-xr-x 1 root root 813 Feb 10  2019 man-db
>
>
> Output of dpkg -l | grep -i apt
>
> ii  apt   1.8.2.3 
> amd64commandline package manager
> ii  apt-config-icons  0.12.5-1
> all  APT configuration snippet to enable icon downloads
> ii  apt-listchanges   3.19
> all  package change history notification tool
> ii  apt-utils 1.8.2.3 
> amd64package management related utility programs
> ii  laptop-detect 0.16
> all  system chassis type checker
> ii  libapt-inst2.0:amd64  1.8.2.3 
> amd64deb package format runtime library
> ii  libapt-pkg5.0:amd64   1.8.2.3 
> amd64package management runtime library
> ii  libatk-adaptor:amd64  2.30.0-5
> amd64AT-SPI 2 toolkit bridge
> ii  libmjpegutils-2.1-0   1:2.1.0+debian-5
> amd64MJPEG capture/editing/replay and MPEG encoding toolset 
> (library)
> ii  libmpeg2encpp-2.1-0   1:2.1.0+debian-5
> amd64MJPEG capture/editing/replay and MPEG encoding toolset 
> (library)
> ii  libmplex2-2.1-0   1:2.1.0+debian-5
> amd64MJPEG capture/editing/replay and MPEG encoding toolset 
> (library)
> ii  libopencore-amrnb0:amd64  0.1.3-2.1+b2
> amd64Adaptive Multi Rate speech codec - shared library
> ii  libopencore-amrwb0:amd64  0.1.3-2.1+b2
> amd64Adaptive Multi-Rate - Wideband speech codec - shared library
> ii  libpcap0.8:amd64  1.8.1-6 
> amd64system interface for user-level packet capture
> ii  python-apt-common 1.8.4.3 
> all  Python interface to libapt-pkg (locales)
> ii  python3-apt   1.8.4.3 
> amd64Python 3 interface to libapt-pkg
> ii  synaptic  0.84.6  
> amd64Graphical package manager
> ii  task-laptop   3.53
> all  laptop
>
Nothing shocking here...

What about the following commands?

cat /etc/anacrontab
systemctl list-timers

Best regards,
l0f4r0

Re: How do I permanently disable unattended downloads of software/security updates?

[Stella Ashburne]

Hi

Thanks for your help and time. I really appreciate it.

> Sent: Wednesday, June 02, 2021 at 3:01 PM
> From: l0f...@tuta.io
> To: "Debian User" 
> Subject: Re: How do I permanently disable unattended downloads of 
> software/security updates?
>
> NB: You do not need `sudo` here.
>
Noted.

> Can you provide us with the output of the following commands?
>
Output of crontab -l

No crontab for username


Output of sudo crontab -l

No crontab for root


Output of cat /etc/crontab

# /etc/crontab: system-wide crontab
# Unlike any other crontab you don't have to run the `crontab'
# command to install the new version when you edit this file
# and files in /etc/cron.d. These files also have username fields,
# that none of the other crontabs do.

SHELL=/bin/sh
PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin

# Example of job definition:
# . minute (0 - 59)
# |  .- hour (0 - 23)
# |  |  .-- day of month (1 - 31)
# |  |  |  .--- month (1 - 12) OR jan,feb,mar,apr ...
# |  |  |  |  . day of week (0 - 6) (Sunday=0 or 7) OR 
sun,mon,tue,wed,thu,fri,sat
# |  |  |  |  |
# *  *  *  *  * user-name command to be executed
17 ** * *   rootcd / && run-parts --report /etc/cron.hourly
25 6* * *   roottest -x /usr/sbin/anacron || ( cd / && run-parts 
--report /etc/cron.daily )
47 6* * 7   roottest -x /usr/sbin/anacron || ( cd / && run-parts 
--report /etc/cron.weekly )
52 61 * *   roottest -x /usr/sbin/anacron || ( cd / && run-parts 
--report /etc/cron.monthly )
#


Output of ls -l /etc/cron.*

/etc/cron.d:
total 4
-rw-r--r-- 1 root root 285 May 19  2019 anacron

/etc/cron.daily:
total 32
-rwxr-xr-x 1 root root  311 May 19  2019 0anacron
-rwxr-xr-x 1 root root 1478 May 12  2020 apt-compat
-rwxr-xr-x 1 root root  355 Dec 29  2017 bsdmainutils
-rwxr-xr-x 1 root root  384 Dec 31  2018 cracklib-runtime
-rwxr-xr-x 1 root root 1187 Apr 19  2019 dpkg
-rwxr-xr-x 1 root root  377 Aug 28  2018 logrotate
-rwxr-xr-x 1 root root 1123 Feb 10  2019 man-db
-rwxr-xr-x 1 root root  249 Sep 27  2017 passwd

/etc/cron.hourly:
total 0

/etc/cron.monthly:
total 4
-rwxr-xr-x 1 root root 313 May 19  2019 0anacron

/etc/cron.weekly:
total 8
-rwxr-xr-x 1 root root 312 May 19  2019 0anacron
-rwxr-xr-x 1 root root 813 Feb 10  2019 man-db


Output of dpkg -l | grep -i apt

ii  apt   1.8.2.3   
  amd64commandline package manager
ii  apt-config-icons  0.12.5-1  
  all  APT configuration snippet to enable icon downloads
ii  apt-listchanges   3.19  
  all  package change history notification tool
ii  apt-utils 1.8.2.3   
  amd64package management related utility programs
ii  laptop-detect 0.16  
  all  system chassis type checker
ii  libapt-inst2.0:amd64  1.8.2.3   
  amd64deb package format runtime library
ii  libapt-pkg5.0:amd64   1.8.2.3   
  amd64package management runtime library
ii  libatk-adaptor:amd64  2.30.0-5  
  amd64AT-SPI 2 toolkit bridge
ii  libmjpegutils-2.1-0   1:2.1.0+debian-5  
  amd64MJPEG capture/editing/replay and MPEG encoding toolset (library)
ii  libmpeg2encpp-2.1-0   1:2.1.0+debian-5  
  amd64MJPEG capture/editing/replay and MPEG encoding toolset (library)
ii  libmplex2-2.1-0   1:2.1.0+debian-5  
  amd64MJPEG capture/editing/replay and MPEG encoding toolset (library)
ii  libopencore-amrnb0:amd64  0.1.3-2.1+b2  
  amd64Adaptive Multi Rate speech codec - shared library
ii  libopencore-amrwb0:amd64  0.1.3-2.1+b2  
  amd64Adaptive Multi-Rate - Wideband speech codec - shared library
ii  libpcap0.8:amd64  1.8.1-6   
  amd64system interface for user-level packet capture
ii  python-apt-common 1.8.4.3   
  all  Python interface to libapt-pkg (locales)
ii  python3-apt   1.8.4.3   
  amd64Python 3 interface to libapt-pkg
ii  synaptic  0.84.6
  amd64Graphical package manager
ii  task-laptop   3.53  
  all  laptop

Re: How do I permanently disable unattended downloads of software/security updates?

[l0f4r0]

Hi Stella,


>> NB: You can still filter `apt-cache rdepends` results with some other 
>> switches like `--no-pre-depends`,  `--no-recommends`,  `--no-suggests`,  
>> `--no-conflicts`,  `--no-breaks`, `--no-replaces` and `--no-enhances`.
>>
>
> Thanks for the above tip.
>
> Can I do something like the following using your above filters?
>
> sudo apt rdepends  --no-recommends
> sudo apt rdepends  --no-suggests
>
Yes, sure but try it by yourself and you'll see it works (with `apt rdepends` 
or even `apt-cache rdepends`)
NB: You do not need `sudo` here.

Can you provide us with the output of the following commands?

crontab -l
sudo crontab -l
cat /etc/crontab
ls -l /etc/cron.*
dpkg -l | grep -i apt


>> NB: If not explicitely mentioned by a debian-user poster, most of the time 
>> (s)he is a subscriber of this mailing-list. At least I am, so you can omit 
>> my email address in each of your answers (I'm currently receiving all your 
>> emails twice) ;)
>>
>
> I apologize if I have caused inconvenience to you and shall remember to 
> remove your email address when I reply to yours.
>
No worries...

Best regards,
l0f4r0

Re: How do I permanently disable unattended downloads of software/security updates?

[Joe]

On Tue, 1 Jun 2021 19:19:23 +0200
Stella Ashburne  wrote:

> Hi
> 
> > Sent: Tuesday, June 01, 2021 at 9:26 PM
> > From: "Joe" 
> > To: debian-user@lists.debian.org
> > Subject: Re: How do I permanently disable unattended downloads of
> > software/security updates? 
> First of all, id you surf using the link to the screenshot? Here's
> the URL again: https://ibb.co/5xP7r5t
> 
> The screenshot shows that my OS surreptitiously downloads the
> software/security updates without my manual intervention. This is not
> what I want and is the subject of my original post.
> 

Can we establish right now that this is neither expected nor default
behaviour from Debian?

Something has been done to be 'helpful' by some entity, and I'd agree
the DE is likely to be to blame, if unattended-upgrades has been ruled
out. I still find it difficult to believe that someone would recreate
the functionality of u-u by other means, but there are a lot of strange
people in Linux... 

A default installation of Debian, without a heavyweight DE, will *not*
do this. Not one of the many Debian installations I have ever run has
ever resulted in this happening, but then I haven't installed either
Gnome or KDE since Gnome 3 arrived.

A possible line of approach: you have a list of the recent downloads.
It is possible that one of the history.log files under /var/log/apt may
be helpful in identifying the time and date of download. The file
/etc/crontab and the files under /etc/cron.d contain timed
instructions. It may be possible to identify the culprit from time and
date correlations.

I do use /etc/crontab myself to run simulated upgrades on my servers
without downloading anything, but sending an email to me if there are
any upgrades available. It will be obvious if you have any cron script
that is doing this kind of thing.

-- 
Joe

Re: How do I permanently disable unattended downloads of software/security updates?

[Reco]

Hi.

On Tue, Jun 01, 2021 at 07:27:22PM +0200, Stella Ashburne wrote:
> > I'm curious what will be shown in this configuration by:
> >
> > apt-config dump | grep Periodic
> >
> One kind person has already asked me for the output of

My bad. I haven't followed this thread closely until now.

> apt-config dump | grep -i APT::Periodic
> 
> Below is the output of the above command:
> 
> APT::Periodic "";
> APT::Periodic::Download-Upgradeable-Packages "0";
> APT::Periodic::Unattended-Upgrade "0";

Ok, that complicates things slightly.
Is there anything that can be attributed to this behaviour at
/var/log/apt/history.log* ? Could be anything, you'll need to evaluate
Start-Date attribute.

Of course, it's unlikely there will be anything, so it's time for an
old magic trick - auditd.
Install auditd package.
Invoke:

auditctl -w /usr/bin/apt -p rx
auditctl -w /usr/bin/apt-get -p rx

Wait for the next occurence of the problem, to speed things up - invoke
"apt clean".
To know exact time someone invoked apt without your knowledge - invoke
"ausearch -f /usr/bin/apt -i".

Once you know an exact time the problem happens - it should be trivial
to search, say, journald entries for anything related.

In short, dear listers, auditd. Have it, use it. Thing solves issues,
and does it in non-intrusive way.


Oh, and another question. Do you happen to have packagekit to be
installed? This Fine Piece™ of RedHat middleware (have to keep the
archives list PG-13 compliant, you see ;) is known to perform
questionable tricks like this.

Reco

Re: How do I permanently disable unattended downloads of software/security updates?

[Dan Ritter]

Stella Ashburne wrote: 
> As you can see from the screenshot, my OS has surreptitiously downloaded 
> software/security updates without my manual intervention. This behavior is 
> not what I like and it's the subject of my original post.
> 
> >
> > The devil is in the details, as they say.
> > "sudo apt upgrade" shows that it does not need to download anything,
> > because:
> >
> > > > username@localhost:~$ sudo apt upgrade
> > ...
> > > > Need to get 0 B/20.2 MB of archives.
> >
> Exactly. The notification about software updates being available was the 
> first thing that popped up on my OS (see screenshot: https://ibb.co/5xP7r5t). 
> This was confirmed by the message "Need to get 0 B/20.2 MB of archives".
> 
> > I'm curious what will be shown in this configuration by:
> >
> > apt-config dump | grep Periodic
> >
> One kind person has already asked me for the output of
> 
> apt-config dump | grep -i APT::Periodic
> 
> Below is the output of the above command:
> 
> APT::Periodic "";
> APT::Periodic::Download-Upgradeable-Packages "0";
> APT::Periodic::Unattended-Upgrade "0";

This really looks like something being done by your desktop
system rather than at the OS level.

Fire up dconf-editor, look at org.gnome.software, and see if
"download-updates" is checked. If so, uncheck it.

-dsr-

Re: How do I permanently disable unattended downloads of software/security updates?

[Stella Ashburne]

Hi

> Sent: Tuesday, June 01, 2021 at 9:39 PM
> From: "Reco" 
> To: debian-user@lists.debian.org
> Subject: Re: How do I permanently disable unattended downloads of 
> software/security updates?
>
As you can see from the screenshot, my OS has surreptitiously downloaded 
software/security updates without my manual intervention. This behavior is not 
what I like and it's the subject of my original post.

>
> The devil is in the details, as they say.
> "sudo apt upgrade" shows that it does not need to download anything,
> because:
>
> > > username@localhost:~$ sudo apt upgrade
> ...
> > > Need to get 0 B/20.2 MB of archives.
>
Exactly. The notification about software updates being available was the first 
thing that popped up on my OS (see screenshot: https://ibb.co/5xP7r5t). This 
was confirmed by the message "Need to get 0 B/20.2 MB of archives".

> I'm curious what will be shown in this configuration by:
>
> apt-config dump | grep Periodic
>
One kind person has already asked me for the output of

apt-config dump | grep -i APT::Periodic

Below is the output of the above command:

APT::Periodic "";
APT::Periodic::Download-Upgradeable-Packages "0";
APT::Periodic::Unattended-Upgrade "0";

Re: How do I permanently disable unattended downloads of software/security updates?

[Stella Ashburne]

Hi

> Sent: Tuesday, June 01, 2021 at 9:26 PM
> From: "Joe" 
> To: debian-user@lists.debian.org
> Subject: Re: How do I permanently disable unattended downloads of 
> software/security updates?
>
First of all, id you surf using the link to the screenshot? Here's the URL 
again: https://ibb.co/5xP7r5t

The screenshot shows that my OS surreptitiously downloads the software/security 
updates without my manual intervention. This is not what I want and is the 
subject of my original post.

Re: How do I permanently disable unattended downloads of software/security updates?

[Reco]

Hi.

On Tue, Jun 01, 2021 at 02:26:50PM +0100, Joe wrote:
> > Automatic downloads of software/security downloads took place today,
> > June 1, 2021.
> > 
> > Please click the link to the screenshot: https://ibb.co/5xP7r5t
> > 
> > Please see below for the details:
> > 
> > username@localhost:~$ sudo apt update
> > [sudo] password for username:
> > Hit:1 http://security.debian.org/debian-security buster/updates
> > InRelease Hit:2 http://security.debian.org buster/updates InRelease
> > Hit:3 https://deb.debian.org/debian buster InRelease
> > Hit:4 https://deb.debian.org/debian buster-updates InRelease
> > Hit:5 https://deb.debian.org/debian buster-backports InRelease
> > Reading package lists... Done
> > Building dependency tree
> > Reading state information... Done
> > 4 packages can be upgraded. Run 'apt list --upgradable' to see them.
> > 
> > username@localhost:~$ sudo apt list --upgradable
> > Listing... Done
> > gir1.2-javascriptcoregtk-4.0/stable,stable 2.32.1-1~deb10u1 amd64
> > [upgradable from: 2.30.6-1~deb10u1] gir1.2-webkit2-4.0/stable,stable
> > 2.32.1-1~deb10u1 amd64 [upgradable from: 2.30.6-1~deb10u1]
> > libjavascriptcoregtk-4.0-18/stable,stable 2.32.1-1~deb10u1 amd64
> > [upgradable from: 2.30.6-1~deb10u1]
> > libwebkit2gtk-4.0-37/stable,stable 2.32.1-1~deb10u1 amd64 [upgradable
> > from: 2.30.6-1~deb10u1] username@localhost:~$
> > 
> > username@localhost:~$ sudo apt upgrade
> > Reading package lists... Done
> > Building dependency tree
> > Reading state information... Done
> > Calculating upgrade... Done
> > The following NEW packages will be installed:
> >   xdg-desktop-portal xdg-desktop-portal-gtk
> > The following packages will be upgraded:
> >   gir1.2-javascriptcoregtk-4.0 gir1.2-webkit2-4.0
> > libjavascriptcoregtk-4.0-18 libwebkit2gtk-4.0-37
> > 4 upgraded, 2 newly installed, 0 to remove and 0 not upgraded.
> > Need to get 0 B/20.2 MB of archives.
> > After this operation, 5,118 kB of additional disk space will be used.
> > Do you want to continue? [Y/n]
> > 
> > If you guys notice, 20.2MB of updates have been automatically
> > downloaded in the background (without my manual intervention).
> > 
> 
> So who typed the 'sudo apt update' and 'sudo apt upgrade'?

The devil is in the details, as they say.
"sudo apt upgrade" shows that it does not need to download anything,
because:

> > username@localhost:~$ sudo apt upgrade
...
> > Need to get 0 B/20.2 MB of archives.


I'm curious what will be shown in this configuration by:

apt-config dump | grep Periodic

Reco

Re: How do I permanently disable unattended downloads of software/security updates?

[Joe]

On Tue, 1 Jun 2021 13:15:30 +0200
Stella Ashburne  wrote:

> Hi
> 
> > Sent: Friday, May 28, 2021 at 8:05 PM
> > From: l0f...@tuta.io
> > To: "Debian User" 
> > Subject: Re: How do I permanently disable unattended downloads of
> > software/security updates?
> >
> > 28 mai 2021, 13:43 de l0f...@tuta.io:
> >  
> > > I think you won't update/upgrade automatically anymore (by the
> > > way you say you haven't noticed this behavior so far), but time
> > > will confirm.  
> 
> Time has indeed confirmed my worst fears. Today June 1, 2021 in
> fact...
> 
> > Correction: I meant if you still have updates/upgrades, then it
> > shouldn't be because of package unattended-upgrades. So you would
> > have to dig somewhere else... 
> 
> Automatic downloads of software/security downloads took place today,
> June 1, 2021.
> 
> Please click the link to the screenshot: https://ibb.co/5xP7r5t
> 
> Please see below for the details:
> 
> username@localhost:~$ sudo apt update
> [sudo] password for username:
> Hit:1 http://security.debian.org/debian-security buster/updates
> InRelease Hit:2 http://security.debian.org buster/updates InRelease
> Hit:3 https://deb.debian.org/debian buster InRelease
> Hit:4 https://deb.debian.org/debian buster-updates InRelease
> Hit:5 https://deb.debian.org/debian buster-backports InRelease
> Reading package lists... Done
> Building dependency tree
> Reading state information... Done
> 4 packages can be upgraded. Run 'apt list --upgradable' to see them.
> 
> username@localhost:~$ sudo apt list --upgradable
> Listing... Done
> gir1.2-javascriptcoregtk-4.0/stable,stable 2.32.1-1~deb10u1 amd64
> [upgradable from: 2.30.6-1~deb10u1] gir1.2-webkit2-4.0/stable,stable
> 2.32.1-1~deb10u1 amd64 [upgradable from: 2.30.6-1~deb10u1]
> libjavascriptcoregtk-4.0-18/stable,stable 2.32.1-1~deb10u1 amd64
> [upgradable from: 2.30.6-1~deb10u1]
> libwebkit2gtk-4.0-37/stable,stable 2.32.1-1~deb10u1 amd64 [upgradable
> from: 2.30.6-1~deb10u1] username@localhost:~$
> 
> username@localhost:~$ sudo apt upgrade
> Reading package lists... Done
> Building dependency tree
> Reading state information... Done
> Calculating upgrade... Done
> The following NEW packages will be installed:
>   xdg-desktop-portal xdg-desktop-portal-gtk
> The following packages will be upgraded:
>   gir1.2-javascriptcoregtk-4.0 gir1.2-webkit2-4.0
> libjavascriptcoregtk-4.0-18 libwebkit2gtk-4.0-37
> 4 upgraded, 2 newly installed, 0 to remove and 0 not upgraded.
> Need to get 0 B/20.2 MB of archives.
> After this operation, 5,118 kB of additional disk space will be used.
> Do you want to continue? [Y/n]
> 
> If you guys notice, 20.2MB of updates have been automatically
> downloaded in the background (without my manual intervention).
> 


So who typed the 'sudo apt update' and 'sudo apt upgrade'?

Those are one pair of commands (there are others) to *manually* first
download the list of upgradeable packages and then to download and
install the packages themselves. 

If it was you who typed them, what did you expect them to do? If it
wasn't you who typed them, find out who/what did so.

--
Joe

Re: How do I permanently disable unattended downloads of software/security updates?

[Stella Ashburne]

Hi

> Sent: Friday, May 28, 2021 at 8:05 PM
> From: l0f...@tuta.io
> To: "Debian User" 
> Subject: Re: How do I permanently disable unattended downloads of 
> software/security updates?
>
> 28 mai 2021, 13:43 de l0f...@tuta.io:
>
> > I think you won't update/upgrade automatically anymore (by the way you say 
> > you haven't noticed this behavior so far), but time will confirm.

Time has indeed confirmed my worst fears. Today June 1, 2021 in fact...

> Correction: I meant if you still have updates/upgrades, then it shouldn't be 
> because of package unattended-upgrades. So you would have to dig somewhere 
> else...
>

Automatic downloads of software/security downloads took place today, June 1, 
2021.

Please click the link to the screenshot: https://ibb.co/5xP7r5t

Please see below for the details:

username@localhost:~$ sudo apt update
[sudo] password for username:
Hit:1 http://security.debian.org/debian-security buster/updates InRelease
Hit:2 http://security.debian.org buster/updates InRelease
Hit:3 https://deb.debian.org/debian buster InRelease
Hit:4 https://deb.debian.org/debian buster-updates InRelease
Hit:5 https://deb.debian.org/debian buster-backports InRelease
Reading package lists... Done
Building dependency tree
Reading state information... Done
4 packages can be upgraded. Run 'apt list --upgradable' to see them.

username@localhost:~$ sudo apt list --upgradable
Listing... Done
gir1.2-javascriptcoregtk-4.0/stable,stable 2.32.1-1~deb10u1 amd64 [upgradable 
from: 2.30.6-1~deb10u1]
gir1.2-webkit2-4.0/stable,stable 2.32.1-1~deb10u1 amd64 [upgradable from: 
2.30.6-1~deb10u1]
libjavascriptcoregtk-4.0-18/stable,stable 2.32.1-1~deb10u1 amd64 [upgradable 
from: 2.30.6-1~deb10u1]
libwebkit2gtk-4.0-37/stable,stable 2.32.1-1~deb10u1 amd64 [upgradable from: 
2.30.6-1~deb10u1]
username@localhost:~$

username@localhost:~$ sudo apt upgrade
Reading package lists... Done
Building dependency tree
Reading state information... Done
Calculating upgrade... Done
The following NEW packages will be installed:
  xdg-desktop-portal xdg-desktop-portal-gtk
The following packages will be upgraded:
  gir1.2-javascriptcoregtk-4.0 gir1.2-webkit2-4.0 libjavascriptcoregtk-4.0-18
  libwebkit2gtk-4.0-37
4 upgraded, 2 newly installed, 0 to remove and 0 not upgraded.
Need to get 0 B/20.2 MB of archives.
After this operation, 5,118 kB of additional disk space will be used.
Do you want to continue? [Y/n]

If you guys notice, 20.2MB of updates have been automatically downloaded in the 
background (without my manual intervention).

I appreciate your help in this matter.

Best wishes.

Re: How do I permanently disable unattended downloads of software/security updates?

[Dan Ritter]

Stella Ashburne wrote: 
> 
> Question: Is it a prerequisite (pre-condition) that to set up a cron job to 
> download updates at a fixed time every day, the OS must have the installed 
> package "unattended-upgrades"?
> 

No.

apt install apticron

will get you a customizable cron job that will:

- update the package lists daily
- optionally download but not install updated packages
- send you mail about updated packages (at an address of your
  choice)

-dsr-

Re: How do I permanently disable unattended downloads of software/security updates?

[Charles Curley]

On Sun, 30 May 2021 13:08:18 +0200
Stella Ashburne  wrote:

> My knowledge of computing, Linux and Debian is elementary and hence I
> won't know how to set up a cron-apt or use apticron.
> 
> Question: Is it a prerequisite (pre-condition) that to set up a cron
> job to download updates at a fixed time every day, the OS must have
> the installed package "unattended-upgrades"?

No, unattended upgrades is not a requirement.

I used the following cron job for years until recently. I started using
something like it when I was on dial-up and wanted to speed up the
upgrade process by having the new packages already on my computers.
Over the past year or so I have phased in unattended-upgrades.

5  3  ***   root/usr/bin/apt-get update 
> /dev/null && /usr/bin/apt-get -dy dist-upgrade > /dev/null

(That is all one line. I expect your mail reader will wrap it horribly.
When you copy and paste it, straighten it out into all one line.)

I suggest that, as root, you put it in its own unique file
in /etc/cron.d. That way it will survive updates to other files.

A brief explanation of what it does:

At 03:05 every morning, as root, run apt-get update to update
apt-get's cache. If that's successful (the &&), run apt-get dist-upgrade
for downloads only (-d) and assume a "yes" answer to all questions
(-y). In both cases, discard the standard output by sending it to the
null device.

-- 
Does anybody read signatures any more?

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

Re: How do I permanently disable unattended downloads of software/security updates?

[Greg Wooledge]

On Sun, May 30, 2021 at 01:08:18PM +0200, Stella Ashburne wrote:
> Question: Is it a prerequisite (pre-condition) that to set up a cron job to 
> download updates at a fixed time every day, the OS must have the installed 
> package "unattended-upgrades"?

Nope.  You can write your own cron job to do it.

The thing is, the simple and obvious way to do it via cron is slightly
dangerous.  When cron runs apt-get or apt or whatever you choose, *you*
have no ability to interact with it.  If a package comes with a
NEWS.Debian.gz file that it wants to display to you to warn you about
some new incompatible change, or if it wants to ask you whether it should
replace a conffile that has been altered, or *any* kind of question,
it can't.

So, the simple and obvious workaround for that, when writing a cron job
to do this, would be to use apt-get's "-y" flag.

This may not do what you want in all situations.

On the other hand, your question is interesting, in that it says "download
updates", not "install updates".  If you really do mean "download the
packages and let them sit in /var/cache but don't install them", then
there's no danger.  You can write a cron job to do that, no problem at
all.

Of course, then the question becomes one of your workflow.  Are you going
to look in /var/cache/apt/archives/ yourself once a day, to see whether
there's a new file there?  Are you going to set up your cron job to email
you whenever a package is downloaded?  Are you simply going to run
"apt-get -u upgrade" or some equivalent once a day?  There are lots of
possibilities here.  You just have to decide what you want, and then
implement it.

Re: How do I permanently disable unattended downloads of software/security updates?

[Stella Ashburne]

Hi

> Sent: Sunday, May 30, 2021 at 7:00 PM
> From: to...@tuxteam.de
> To: "Stella Ashburne" 
> Cc: "Greg Wooledge" , debian-user@lists.debian.org
> Subject: Re: How do I permanently disable unattended downloads of 
> software/security updates?
>
> Not Greg here, but... yes, you can do that. And there's even a man
> page :)

Thanks for your reply.

Best wishes.

Re: How do I permanently disable unattended downloads of software/security updates?

[Stella Ashburne]

Hi

Thanks for your help and time. I really appreciate it.

> Sent: Saturday, May 29, 2021 at 5:29 PM
> From: l0f...@tuta.io
> To: "Debian User" 
> Subject: Re: How do I permanently disable unattended downloads of 
> software/security updates?
>
> NB: You can still filter `apt-cache rdepends` results with some other 
> switches like `--no-pre-depends`,  `--no-recommends`,  `--no-suggests`,  
> `--no-conflicts`,  `--no-breaks`, `--no-replaces` and `--no-enhances`.

Thanks for the above tip.

Can I do something like the following using your above filters?

sudo apt rdepends  --no-recommends
sudo apt rdepends  --no-suggests


> 
> As said Socrates: "I know that I do not know.". It happens everyday for me ;p
>

I think you're being modest. You know so much more than me.

> Back to your question, here are other suggestions I can think about:
> * cron-apt
> * apticron (its goal is only to send notifications by emails but it certainly 
> triggers `apt update` to do that. So maybe this update triggers some other 
> things from your side as well, like widgets...)
> * widgets/applets for your favorite desktop environment (I can't help you, I 
> don't use any...)

My knowledge of computing, Linux and Debian is elementary and hence I won't 
know how to set up a cron-apt or use apticron.

Question: Is it a prerequisite (pre-condition) that to set up a cron job to 
download updates at a fixed time every day, the OS must have the installed 
package "unattended-upgrades"?

> 
> NB: If not explicitely mentioned by a debian-user poster, most of the time 
> (s)he is a subscriber of this mailing-list. At least I am, so you can omit my 
> email address in each of your answers (I'm currently receiving all your 
> emails twice) ;)
>

I apologize if I have caused inconvenience to you and shall remember to remove 
your email address when I reply to yours.

Best regards.

Re: How do I permanently disable unattended downloads of software/security updates?

[tomas]

On Sun, May 30, 2021 at 12:45:13PM +0200, Stella Ashburne wrote:

[...]

> Thanks for your observation about tasksel and autoremove.
> 
> About the only time that I encountered tasksel was during the installation of 
> Debian.
> 
> Since you mentioned tasksel in your reply, how do you invoke tasksel? Do you 
> just type tasksel in a terminal?

Not Greg here, but... yes, you can do that. And there's even a man
page :)

Cheers
 - t


signature.asc
Description: Digital signature

Re: How do I permanently disable unattended downloads of software/security updates?

[Stella Ashburne]

Hi Andrei

> Sent: Saturday, May 29, 2021 at 3:06 PM
> From: "Andrei POPESCU" 
> To: debian-user@lists.debian.org
> Subject: Re: How do I permanently disable unattended downloads of 
> software/security updates?
>
> aptitude was deprecated for some very specific uses only (in particular
> dist-upgrades), not because it couldn't do them, but because APT found
> better solutions. It also didn't help that development of aptitude was
> stopped for a while.

Yeah, I remember somewhat clearly that someone in www.reddit.com/r/debian 
advised me to use "sudo apt upgrade" instead of aptitude because with the 
former, I can see the green-colored progress bar during the installation of 
packages.

>
> In this particular case, apt doesn't have a 'why' command, hence the
> suggestion to use aptitude instead.
>

Thanks for your advice and time. I really appreciate it.

Best regards.

Re: How do I permanently disable unattended downloads of software/security updates?

[Stella Ashburne]

Hi Greg,

> Sent: Saturday, May 29, 2021 at 8:58 PM
> From: "Greg Wooledge" 
> To: debian-user@lists.debian.org
> Subject: Re: How do I permanently disable unattended downloads of 
> software/security updates?
>
> tasksel will also perform an autoremove for you without asking you.
> It was after this happened to me that I investigated how to disable
> apt's autoremove feature.
>

Thanks for your observation about tasksel and autoremove.

About the only time that I encountered tasksel was during the installation of 
Debian.

Since you mentioned tasksel in your reply, how do you invoke tasksel? Do you 
just type tasksel in a terminal?

Re: How do I permanently disable unattended downloads of software/security updates?

[Andrei POPESCU]

On Sb, 29 mai 21, 19:09:36, Stella Ashburne wrote:
> Hello Andrei
> 
> Thank you for your advice and time. I really appreciate it.
> 
> > Sent: Saturday, May 29, 2021 at 2:49 PM
> > From: "Andrei POPESCU" 
> > To: debian-user@lists.debian.org
> > Subject: Re: How do I permanently disable unattended downloads of 
> > software/security updates?
> >
> > Removing files belonging to a package is typically frowned upon, as this
> > can under specific circumstances be like pulling the rug from underneath
> > a package (or worse, APT/dpkg).
> 
> Oops. I removed/deleted the file 50unattended-upgrades located in 
> /etc/apt/apt.conf.d/
> >
> > In the case of configuration files (basically everything that is under
> > /etc and a few other places) it can cause unexpected or even unsafe
> > behaviour as the software might revert to built-in defaults that could
> > be wrong for your system.
> 
> I suppose 50unattended-upgrades is a configuration file?

Yes. You also disabled the background service, so it should be fine.

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


signature.asc
Description: PGP signature

Re: How do I permanently disable unattended downloads of software/security updates?

[Stella Ashburne]

Hello Andrei

Thank you for your advice and time. I really appreciate it.

> Sent: Saturday, May 29, 2021 at 2:49 PM
> From: "Andrei POPESCU" 
> To: debian-user@lists.debian.org
> Subject: Re: How do I permanently disable unattended downloads of 
> software/security updates?
>
> Removing files belonging to a package is typically frowned upon, as this
> can under specific circumstances be like pulling the rug from underneath
> a package (or worse, APT/dpkg).

Oops. I removed/deleted the file 50unattended-upgrades located in 
/etc/apt/apt.conf.d/
>
> In the case of configuration files (basically everything that is under
> /etc and a few other places) it can cause unexpected or even unsafe
> behaviour as the software might revert to built-in defaults that could
> be wrong for your system.

I suppose 50unattended-upgrades is a configuration file?

Best regards.

Re: How do I permanently disable unattended downloads of software/security updates?

[Greg Wooledge]

On Sat, May 29, 2021 at 09:49:06AM +0300, Andrei POPESCU wrote:
> In the case of configuration files (basically everything that is under 
> /etc and a few other places) it can cause unexpected or even unsafe 
> behaviour as the software might revert to built-in defaults that could 
> be wrong for your system.

Also worth noting: if you remove a conffile and then think "Oops, I
didn't mean to do that, let me reinstall the package to get it back",
you will be surprised.  The conffile will not be replaced.  Your action
of deleting the conffile while retaining the package is explicitly
noted by the package manager, and respected as a conscious choice.

If you want to replace a deleted conffile, you may either *purge* the
package and then reinstall it, or use the --force-confmiss flag to dpkg.


On Sat, May 29, 2021 at 10:06:09AM +0300, Andrei POPESCU wrote:
> APT (the software package) doesn't autoremove packages, though it might 
> suggest you to do that when you use the 'apt' command.
> 
> aptitude in its default configuration will do so on every occasion, so 
> you might want to avoid using it for package installs, removals, etc.

tasksel will also perform an autoremove for you without asking you.
It was after this happened to me that I investigated how to disable
apt's autoremove feature.

See also .

Re: How do I permanently disable unattended downloads of software/security updates?

[l0f4r0]

Hi,

29 mai 2021, 09:06 de andreimpope...@gmail.com: 

>> Question: What command can I type in a terminal to find out if the 
>> package "unattended-upgrades" is a *dependency* of some other 
>> packages?
>>
> These should do it.
>
> apt rdepends unattended-upgrades
>
> Read as "the reverse depends of", though it will also include other 
> package relationships.
>
> aptitude search '?depends(unattended-upgrades)'
>
> Read as "packages that depend on". This is interpreted literally, i.e. 
> it won't show any other package relationship (like Recommends).
>
I didn't know about `apt rdepends` thanks.
It appears the result is more explicit than `apt-cache rdepends`, that's a good 
point (easy to grep).

What is less good is that it's very easy to forget this behavior difference 
with time (like many things).
There are so many commands and possibilities around APT, it can be confusing 
sometimes...

NB: You can still filter `apt-cache rdepends` results with some other switches 
like `--no-pre-depends`,  `--no-recommends`,  `--no-suggests`,  
`--no-conflicts`,  `--no-breaks`, `--no-replaces` and `--no-enhances`.

29 mai 2021, 01:32 de rewe...@gmx.com:

> Oh my God, are you telling me that we are not done with this "whatever thing 
> you may call it"? I thought I could close this matter..lol
>
> Based on your vast experience of using Linux in general and Debian in 
> particular, can you think of any other packages or files that could download 
> software and security updates silently in the background?
>
"Vast experience"? I think you are probably flattering me lol
As said Socrates: "I know that I do not know.". It happens everyday for me ;p

Back to your question, here are other suggestions I can think about:
* cron-apt
* apticron (its goal is only to send notifications by emails but it certainly 
triggers `apt update` to do that. So maybe this update triggers some other 
things from your side as well, like widgets...)
* widgets/applets for your favorite desktop environment (I can't help you, I 
don't use any...)

NB: If not explicitely mentioned by a debian-user poster, most of the time 
(s)he is a subscriber of this mailing-list. At least I am, so you can omit my 
email address in each of your answers (I'm currently receiving all your emails 
twice) ;)

Best regards,
l0f4r0

Re: How do I permanently disable unattended downloads of software/security updates?

[Andrei POPESCU]

On Vi, 28 mai 21, 20:40:23, Stella Ashburne wrote:
> 
> Question: Instead of using "aptitude why unattended-upgrades" command, 
> can I use "apt why unattended-upgrades"? I was told many years ago 
> that the command "aptitude" was deprecated.
 
aptitude was deprecated for some very specific uses only (in particular 
dist-upgrades), not because it couldn't do them, but because APT found 
better solutions. It also didn't help that development of aptitude was 
stopped for a while.

aptitude is currently still irreplaceable for some uses.

In this particular case, apt doesn't have a 'why' command, hence the 
suggestion to use aptitude instead.
 
> Question: What command can I type in a terminal to find out if the 
> package "unattended-upgrades" is a *dependency* of some other 
> packages?

These should do it.

apt rdepends unattended-upgrades

Read as "the reverse depends of", though it will also include other 
package relationships.


aptitude search '?depends(unattended-upgrades)'

Read as "packages that depend on". This is interpreted literally, i.e. 
it won't show any other package relationship (like Recommends).


> I wish to improve my knowledge of computing. How do I disable 
> autoremove? What is the command to be typed in a terminal?

APT (the software package) doesn't autoremove packages, though it might 
suggest you to do that when you use the 'apt' command.

aptitude in its default configuration will do so on every occasion, so 
you might want to avoid using it for package installs, removals, etc.


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


signature.asc
Description: PGP signature

Re: How do I permanently disable unattended downloads of software/security updates?

[Andrei POPESCU]

On Vi, 28 mai 21, 02:44:30, Stella Ashburne wrote:
> 
> The reason is that I find it too drastic a step. I chose to disable by 
> doing sudo systemctl disable unattended-upgrades. I did delete the 
> package called 50unattended-upgrades (as mentioned in my original 
> post.)

Installing packages on Debian is so easy that in most cases purging a 
package is a very safe method to disable a specific functionality.

Removing files belonging to a package is typically frowned upon, as this 
can under specific circumstances be like pulling the rug from underneath 
a package (or worse, APT/dpkg).

In the case of configuration files (basically everything that is under 
/etc and a few other places) it can cause unexpected or even unsafe 
behaviour as the software might revert to built-in defaults that could 
be wrong for your system.

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


signature.asc
Description: PGP signature

Re: How do I permanently disable unattended downloads of software/security updates?

[Stella Ashburne]

Hello,

Thanks for your help and time. I really appreciate it.

> Sent: Saturday, May 29, 2021 at 2:51 AM
> From: "Greg Wooledge" 
> To: debian-user@lists.debian.org
> Subject: Re: How do I permanently disable unattended downloads of 
> software/security updates?
>
> > Question: What do you mean by "a metapackage is not critically important"? 
> > Would you like to elaborate please?
>
> Take a look at "apt show gnome", for example.
>
> On bullseye, on my platform, the package "gnome" (which is a metapackage)
> has an Installed-Size of 35.8 kB.  It doesn't contain any software.  All
> it really contains are Depends: and Recommends: and Suggests: lines.  If
> you install this package, it will bring in a whole bunch of new packages
> (unless you already installed GNOME, in which case it may do nothing).
>
> Once all of those packages are installed, you can go ahead and remove
> the package named "gnome".  It doesn't do anything.  It's just a metapackage.

Thank you for explaining why a metapackage is not critically important. I'm a 
bit wiser now :)

> Well... OK, I'll tell you how I did it.  It's easily reversible, so it
> won't hurt you.
>
> I did it by creating the file /etc/apt/apt.conf.d/99local with the
> following content (one line):
>
> APT::NeverAutoRemove ".";
>
> What this configuration file does is define a regular expression that
> matches every package, and then tells apt never to autoremove any package
> that matches that regular expression.
>
> If you want to go back to normal, simply remove that file.

Thank you very much for your example.

Best wishes.