Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.user > #274023 > unrolled thread

Re: lower cpu speed

Back to article view | Back to linux.debian.user

Contents

  Re: lower cpu speed David Wright <deblis@lionunicorn.co.uk> - 2024-10-25 04:30 +0200
    Re: lower cpu speed David Wright <deblis@lionunicorn.co.uk> - 2024-10-25 04:40 +0200
      Re: lower cpu speed eben@gmx.us - 2024-10-25 15:20 +0200
        Re: lower cpu speed Hans <hans.ullrich@loop.de> - 2024-10-25 15:50 +0200
    Re: lower cpu speed eben@gmx.us - 2024-10-25 15:20 +0200
      Re: lower cpu speed David Wright <deblis@lionunicorn.co.uk> - 2024-10-25 21:20 +0200

#274023 — Re: lower cpu speed

On Thu 24 Oct 2024 at 20:34:18 (-0400), eben@gmx.us wrote:
> On 10/24/24 20:01, David Wright wrote:
> > Because of the ownership:
> >
> >    $ ls -l /var/cache/apt/archives/
> >    total 4
> >    -rw-r----- 1 root root    0 Apr 16  2022 lock
> >    drwx------ 2 _apt root 4096 Oct 22 19:00 partial
> >    $
> >
> > we can assume that _apt is the user that actually downloads packages
> > (into partial/) before APT installs them. But your assumption that
> > tmp_sh can be read by any user (including _apt) is wrong: you need
> > execute permission on all directories traversed along the path, even
> > when you “know what you're looking for”.

Apologies ditto.

> Fair enough.  Should I chmod a+x /root/.synaptic/tmp then, or is there a
> nicer way?

Not using synaptic, I don't know why that path was chosen. But
you'd need world-execute all the way down from /root itself.

When I install yt-dlp, being lazy I download the package from
packages.debian.org, choosing the most recent version, typically
trixie's. I store it under /home/debian/trixie (or whatever), and
  # apt-get install full-path
I consider this safe, and ignore the warning that's issued. IIRC,
my warning starts with "N: Download is performed … ".

I do this because I'm too lazy to change my sources.list, and
that has the side-effect that I can't accidentally install any
non-stable packages by way of Depends/Recommends/Suggests.

In the past I have placed packages in /var/cache/apt/archives/,
but I'm not sure whether I used apt-get with a full path,
or dpkg -i; it was so long ago.

> Also, I've been running synaptic as "sudo synaptic" and this is the first
> time I've got that message.

Well, I'll admit that I'm mystified as to what the 283682-byte file
called tmp_sh actually is, and how it was obtained.

> I used to do "synaptic-pkexec" but it would ask
> me for my password each time I ran it, whereas with sudo if I ran it from
> the same terminal again within a few minutes, my previous authentication was
> good enough.

What I've never resolved is under what circumstances does
  # apt-get install full-path
copy full-path via /var/cache/apt/archives/partial/ into
/var/cache/apt/archives/, leaving the copy in the cache,
and install it from there; or just install it directly
from full-path without all the copying. But I suspect that:
. performing the copying step ⇒ no warning,
. installing directly ⇒ warning issued.

Cheers,
David.

[toc] | [next] | [standalone]

#274024

On Thu 24 Oct 2024 at 21:20:28 (-0500), David Wright wrote:

[ … ]

> Apologies ditto.

That should have read:

Apologies, BTW, for losing the threading, but for some reason, my
email host rejected so many permutations of my post (nine, in fact)
that it became apparent the problem might lie in the headers rather
than the body. (For example, having Reply-to = To scores really badly.)

Anyway, it appears I can't reply to eben's posts in this thread but,
if this gets through, I can reply to my own. (And to Daniel Roberts
earlier.) What triggers their spam detector software, presumably
"mailclean11", I have no idea.

Cheers,
David.

[toc] | [prev] | [next] | [standalone]

#274036

On 10/24/24 22:33, David Wright wrote:
 > Anyway, it appears I can't reply to eben's posts in this thread but,
 > if this gets through, I can reply to my own. (And to Daniel Roberts
 > earlier.) What triggers their spam detector software, presumably
 > "mailclean11", I have no idea.

I don't know why I'm special.  I'm using Thunderbird and my mail goes out
through gmx.us.

--
   Hanlon's Razor: "Never attribute to malice that which can be
adequately explained by stupidity."  Derived from Robert Heinlein

[toc] | [prev] | [next] | [standalone]

#274039

Eben, don't worry, got into same issue with some mails sent from debian.

These are then marked with the "*****SPAM*****" tag in the header, althpough  
it is no spam. It as someting to do with DKIM. I already noticed debian of it, 
but they say, they are not responsible and some other mailer is doing wrong 
things (in my case it shall be megamail). I have to bleive them, but it 
woinders, why only mails from are affected this way. 

But before starting some anger somewhere, I made my own spamrule and set mails 
from debian to the whitelist in my spamrules = issue solved.

However, it might also still effect other people, but do not know and can not 
prove it.

Just for info.....

Best regards

Hans
> I don't know why I'm special.  I'm using Thunderbird and my mail goes out
> through gmx.us.
> 
> --
>    Hanlon's Razor: "Never attribute to malice that which can be
> adequately explained by stupidity."  Derived from Robert Heinlein

[toc] | [prev] | [next] | [standalone]

#274037

On 10/24/24 22:20, David Wright wrote:
> On Thu 24 Oct 2024 at 20:34:18 (-0400), eben@gmx.us wrote:
>> On 10/24/24 20:01, David Wright wrote:
>>> Because of the ownership:
>>>
>>>     $ ls -l /var/cache/apt/archives/
>>>     total 4
>>>     -rw-r----- 1 root root    0 Apr 16  2022 lock
>>>     drwx------ 2 _apt root 4096 Oct 22 19:00 partial
>>>     $
>>>
>>> we can assume that _apt is the user that actually downloads packages
>>> (into partial/) before APT installs them. But your assumption that
>>> tmp_sh can be read by any user (including _apt) is wrong: you need
>>> execute permission on all directories traversed along the path, even
>>> when you “know what you're looking for”.
>
> Apologies ditto.
>
>> Fair enough.  Should I chmod a+x /root/.synaptic/tmp then, or is there a
>> nicer way?
>
> Not using synaptic, I don't know why that path was chosen. But
> you'd need world-execute all the way down from /root itself.
>
> When I install yt-dlp, being lazy I download the package from
> packages.debian.org, choosing the most recent version, typically
> trixie's. I store it under /home/debian/trixie (or whatever), and
>    # apt-get install full-path
> I consider this safe, and ignore the warning that's issued. IIRC,
> my warning starts with "N: Download is performed … ".
>
> I do this because I'm too lazy to change my sources.list, and
> that has the side-effect that I can't accidentally install any
> non-stable packages by way of Depends/Recommends/Suggests.
>
> In the past I have placed packages in /var/cache/apt/archives/,
> but I'm not sure whether I used apt-get with a full path,
> or dpkg -i; it was so long ago.
On 10/24/24 22:20, David Wright wrote:
> On Thu 24 Oct 2024 at 20:34:18 (-0400), eben@gmx.us wrote:
>> On 10/24/24 20:01, David Wright wrote:
>>> Because of the ownership:
>>>
>>>     $ ls -l /var/cache/apt/archives/
>>>     total 4
>>>     -rw-r----- 1 root root    0 Apr 16  2022 lock
>>>     drwx------ 2 _apt root 4096 Oct 22 19:00 partial
>>>     $
>>>
>>> we can assume that _apt is the user that actually downloads packages
>>> (into partial/) before APT installs them. But your assumption that
>>> tmp_sh can be read by any user (including _apt) is wrong: you need
>>> execute permission on all directories traversed along the path, even
>>> when you “know what you're looking for”.
>
>> Fair enough.  Should I chmod a+x /root/.synaptic/tmp then, or is there a
>> nicer way?
>
> Not using synaptic, I don't know why that path was chosen. But
> you'd need world-execute all the way down from /root itself.

Well the chmod thing is not acceptable.

> Well, I'll admit that I'm mystified as to what the 283682-byte file
> called tmp_sh actually is, and how it was obtained.

eben@cerberus:~$ sudo file /root/.synaptic/tmp/tmp_sh
[sudo] password for eben:
/root/.synaptic/tmp/tmp_sh: PNG image data, 825 x 861, 8-bit/color RGBA,
non-interlaced

I asked for a screenshot of some package, and that appears to be it.  As to
why it's there, couldn't say.  I don't need to save it for posterity or
anything.

It's only a warning so not critical to fix, so I guess I have time to try
non-destructive means of making it not happen.  Thanks.

--
                Maturity is when you stop
              complaining and making excuses,
                 and start making changes.
                     -- Ngoma_r on Reddit

[toc] | [prev] | [next] | [standalone]

#274057

On Fri 25 Oct 2024 at 09:19:30 (-0400), eben@somewhere wrote:
> > Not using synaptic, I don't know why that path was chosen. But
> > you'd need world-execute all the way down from /root itself.
> 
> Well the chmod thing is not acceptable.

Totally reasonable; any world-readable file in /root
would be exposed to being copied out by anybody.

> > Well, I'll admit that I'm mystified as to what the 283682-byte file
> > called tmp_sh actually is, and how it was obtained.
> 
> eben@cerberus:~$ sudo file /root/.synaptic/tmp/tmp_sh
> [sudo] password for eben:
> /root/.synaptic/tmp/tmp_sh: PNG image data, 825 x 861, 8-bit/color RGBA,
> non-interlaced
> 
> I asked for a screenshot of some package, and that appears to be it.  As to
> why it's there, couldn't say.  I don't need to save it for posterity or
> anything.

If it's a screenshot, it was presumably taken over two years ago.
I have no idea why it's involved in the current discussion, but
it does show the value of pasting commands and their output into
posts, as so often mentioned here.

When I receive this warning, the surrounding context relates to
the /package/ file mentioned in the warning:

  # apt-get install ./yt-dlp_2023.01.06-1_all.deb
  Reading package lists... Done
  Building dependency tree... Done
  Reading state information... Done
  Note, selecting 'yt-dlp' instead of './yt-dlp_2023.01.06-1_all.deb'
  Suggested packages:
    libfribidi-bin | bidiv phantomjs
  The following NEW packages will be installed:
    yt-dlp
  0 upgraded, 1 newly installed, 0 to remove and 0 not upgraded.
  Need to get 0 B/1739 kB of archives.
  After this operation, 9644 kB of additional disk space will be used.
  Get:1 /root/yt-dlp_2023.01.06-1_all.deb yt-dlp all 2023.01.06-1 [1739 kB]
  [ … ]
  Preparing to unpack .../yt-dlp_2023.01.06-1_all.deb ...
  Unpacking yt-dlp (2023.01.06-1) ...
  Setting up yt-dlp (2023.01.06-1) ...
  [ … ]
  N: Download is performed unsandboxed as root as file
  '/root/yt-dlp_2023.01.06-1_all.deb' couldn't be accessed
  by user '_apt'. - pkgAcquire::Run (13: Permission denied)
  # 

This shows a consistent view of a package file being installed.
I was writing under the misapprehension that your 283682-byte
file was a temporary copy of a package file with a bizarre name
and a plausible timestamp.

Was Synaptic/APT/dpkg trying to install it?

> It's only a warning so not critical to fix, so I guess I have time to try
> non-destructive means of making it not happen.  Thanks.

I'm an "su -" person that doesn't run GUIs as root, so I'm not best
equipped to know how to avoid the synaptic-pkexec issue except by
not quitting, but leaving it running, say, in a taskbar or whatever.
What happens if you sudo synaptic-pkexec?

I ignore the warning because when I'm using apt-get install full-path,
my level of paranoia is assuaged by checking the MD5 listed at the
bottom of the p.d.o/…/download page before I install it.

If I desperately wanted to avoid it, the easiest way would be to place
the package file into /tmp/ with world-readable permission, and
apt-get install it from there¹, but I don't see the point.

As for posting replies to your posts, the ridiculous thing about
the spam detector is that I can only see what it says about messages
that pass, so it's difficult to guess what can raise the score on
a specific post. However, I (and anybody else) do see lines like:
        RSPAMD_URIBL(3.00)[---.--:email];
                           ↑↑↑↑↑↑ erased your address
caused by the attribution in /just/ the body. Perhaps having that
address in the In-reply-to and References as well is enough to
tip the balance. This post includes those headers but no mention
in the body, so we'll see.

¹ I just tested that with:
  $ namei -l /tmp/yt-dlp_2024.10.22-1_all.deb
  f: /tmp/yt-dlp_2024.10.22-1_all.deb
  drwxr-xr-x root  root  /
  drwxrwxrwt root  root  tmp
  -rw-r--r-- auser auser yt-dlp_2024.10.22-1_all.deb
  $ md5sum /tmp/yt-dlp_2024.10.22-1_all.deb
  b1cdd6f0b2e50cc875017fa9547d209c  /tmp/yt-dlp_2024.10.22-1_all.deb
  $ 

Cheers,
David.

[toc] | [prev] | [standalone]

Back to top | Article view | linux.debian.user

csiph-web