Re: moving some packages back to bookworm stable

[Greg Wooledge]

On Tue, May 28, 2024 at 07:09:16AM -0400, Michael Grant wrote:
> On Tue, May 28, 2024 at 06:59:50AM -0400, Greg Wooledge wrote:
> > On Tue, May 28, 2024 at 06:10:11AM -0400, Michael Grant wrote:
> > > The following packages will be REMOVED:
> > >   [...] libdb5.3t64 [...]
> > 
> > You've *clearly* still got testing packages installed.
> 
> YES.  As I originally said, I created this mess by installing sendmail
> from testing.  And then, a month or so later, I did an
> apt-get upgrade (to do updates, not a full upgrade) which pulled in
> some more things from testing.  I'm trying to get back to all being
> from stable.

So, which part are you confused about?  Did you think there was some
easy way to FIX a frankendebian?  Are you confused because you keep
thinking "there must be some single apt command that will do all the
work for me"?

There's not.  You get to do all the work by hand.

You will most likely need to remove the testing versions of these packages
(apache2, git and so on) and then install the bookworm versions afterward.

The things to watch out for are config files (hence your backup), and
any crazy dependency situations.  In the ideal case, you'll simply be
able to remove all the packages that aren't libs, then downgrade the
libs, then reinstall the packages.  And make sure you have sensible
config files.  If you get stuck, there's always the big hammer
(dpkg --force-depends and so on).

If/when it breaks, you get to reinstall from scratch.

This is why we tell people DO NOT MIX BINARY PACKAGES FROM MULTIPLE
RELEASES.

Re: moving some packages back to bookworm stable

[Greg Wooledge]

On Tue, May 28, 2024 at 06:10:11AM -0400, Michael Grant wrote:
> The following packages will be REMOVED:
>   [...] libdb5.3t64 [...]

You've *clearly* still got testing packages installed.

Re: "Repeaters", etc.

[Greg Wooledge]

On Mon, May 27, 2024 at 05:09:02PM -0400, Paul M Foster wrote:
> (WHY aren't new houses wired with Cat5/6/7?)

Because to the average person, "Internet access" equals "wifi".  They
use the terms interchangeably.

Also, some recent model laptops no longer have an ethernet port.  If you
want to connect to a physical network, you need to buy a USB ethernet
adapter.

Re: moving some packages back to bookworm stable

[Greg Wooledge]

On Mon, May 27, 2024 at 10:28:37AM -0400, Michael Grant wrote:
> On Mon, May 27, 2024 at 10:19:48AM -0400, Greg Wooledge wrote:
> > On Mon, May 27, 2024 at 09:56:54AM -0400, Michael Grant wrote:
> > > I needed to install a version of sendmail from testing a while back to
> > > test it.
> > 
> > Your subject header says "bookworm stable".  You don't install binary
> > packages from testing on a stable system.  You use backports instead.
> 
> ugh no, wait, I may be using the wrong terminology.  I'm not wanting
> to install special packages and definitely don't need to build my own.
> 
> What I want to do is get the system back to just using the packages
> from stable rather than testing.  Only those few packages before
> things get worse in the next update.  There's not many.

Downgrading essential libraries (libc6 and friends) that were brought
in when you tainted your stable system with testing packages is going
to be risky.

Definitely make a backup before you do ANYTHING.

Once that's done, you can try purging the non-essential testing packages,
and then downgrading the essential ones.  If at any point the system
becomes utterly broken, reinstall stable, and then restore your backup.

Re: moving some packages back to bookworm stable

[Greg Wooledge]

On Mon, May 27, 2024 at 09:56:54AM -0400, Michael Grant wrote:
> I needed to install a version of sendmail from testing a while back to
> test it.

Your subject header says "bookworm stable".  You don't install binary
packages from testing on a stable system.  You use backports instead.

https://backports.debian.org/Instructions/

There is already a bookworm backported version of sendmail available:

https://packages.debian.org/search?keywords=sendmail=names=all=bookworm-backports

If that one isn't new enough, then you may need to build your own backport
package.  This is usually either trivially easy ("type these commands")
or utterly impossible, depending on which dependencies have changed
since bookworm.  There's no in-between.

Re: Address 127.0.1.1

[Greg Wooledge]

On Fri, May 24, 2024 at 01:49:58PM -0400, Jeffrey Walton wrote:
> On Fri, May 24, 2024 at 1:46 PM Greg Wooledge  wrote:
> >
> > On Fri, May 24, 2024 at 01:40:38PM -0400, Jeffrey Walton wrote:
> > > On Fri, May 24, 2024 at 11:13 AM Paul M Foster  
> > > wrote:
> > > > 192.168.254.30  yosemite.mars.lan   yosemite
> >
> > > 127.0.1.1 is traditionally used for the fully qualified domain name
> > > (fqdn). So I would expect to see 'yosemite.mars.lan', but not
> > > 'yosemite'.
> >
> > I don't know why you would expect that.  What purpose would that serve?
> 
> Sorry I was not clear. I would expect that because 127.0.1.1 is
> traditionally used for a fully qualified domain name, not a hostname.

What traditions are you referring to?

Here's Debian's documentation for this whole thing:

https://www.debian.org/doc/manuals/debian-reference/ch05.en.html#_the_hostname_resolution

Re: Address 127.0.1.1

[Greg Wooledge]

On Fri, May 24, 2024 at 01:40:38PM -0400, Jeffrey Walton wrote:
> On Fri, May 24, 2024 at 11:13 AM Paul M Foster  
> wrote:
> > 192.168.254.30  yosemite.mars.lan   yosemite

> 127.0.1.1 is traditionally used for the fully qualified domain name
> (fqdn). So I would expect to see 'yosemite.mars.lan', but not
> 'yosemite'.

I don't know why you would expect that.  What purpose would that serve?

The goal here is for programs to be able to look up "the IP address"
that belongs to $HOSTNAME.

If the hostname is "yosemite", then "yosemite" must appear in the
/etc/hosts file as an alias for whatever made-up FQDN is being used.

This is what Paul has.  What Paul has looks quite reasonable to me.
If 192.168.254.30 is in fact bound to an ethernet interface by a
static configuration (e.g. /etc/network/interfaces) then I would also
say it looks correct.

> Also, fqdn's end in dot '.' to denote the top of the dns tree.

Not in the /etc/hosts file, they don't.  You may be thinking of BIND
configuration files.

I've never IN MY LIFE seen trailing dots on hostnames in /etc/hosts.

Re: Address 127.0.1.1

[Greg Wooledge]

On Fri, May 24, 2024 at 05:22:13PM +0100, Joe wrote:
> Long ago, lo used to be just 127.0.0.1, which is what most people would
> try to ping to check localhost, and what appeared in /etc/hosts. There
> is some subtle reason, which I used to know but have now long forgotten,
> why Debian started using 127.0.1.1 in /etc/hosts instead.

It's not "instead".  It's "in addition".

hobbit:~$ head -n2 /etc/hosts
127.0.0.1   localhost
127.0.1.1   hobbit.wooledge.org hobbit

The first line is traditional.  Exactly what it looks like.

The second line ensures that my hostname will always resolve to a
working IP address.  Lots of programs need that.  Some of the most
common reasons back in the old days were X clients that had been
told to use "myhostname:0" as their $DISPLAY.  If "myhostname" didn't
resolve to a working IP address (one which could contact the X server),
then X client programs wouldn't work.

A lot has changed since then, but the basic principle remains the same.
Some programs are going to expect to be able to open a network connection
to whatever IP address the system's hostname resolves to.  127.0.1.1
serves that purpose, without stepping on 127.0.0.1 which has its own
legacy role to fulfill.

Re: Address 127.0.1.1

[Greg Wooledge]

On Fri, May 24, 2024 at 05:22:14PM +0200, Marco Moock wrote:
> Am 24.05.2024 um 17:17:45 Uhr schrieb to...@tuxteam.de:
> 
> > On Fri, May 24, 2024 at 04:49:18PM +0200, Marco Moock wrote:
> > 
> > [...]
> > 
> > > If you operate mail servers, you must have a FQDN. .lan can't be
> > > used for the global DNS stuff, so set a proper FQDN that belongs to
> > > you.  
> > 
> > I think this is wrong in that sweeping generality.
> 
> In the case it should communicate with other MTAs in the internet, this
> will be true because many of them require a resolvable (also reverse)
> FQDN in HELO/EHLO that matches the IPv4/IPv6 addresses of the server.

Most MTAs do not look in /etc/hosts when reading their configuration.
Whatever name they identify with (in the HELO or EHLO command) comes
from some MTA-specific configuration file.

Thus, the contents of /etc/hosts are for *other* things, not related to
MTA configuration.  Just being able to resolve your own hostname to any
address that "works" is the goal.  127.0.1.1 works well for this, which
is why Debian uses it as the default.  If you've got a static LAN address,
you can use that instead.

Re: Synaptic Update Error

[Greg Wooledge]

On Fri, May 24, 2024 at 08:14:16AM -0400, Stephen P. Molnar wrote:
> E: Release file for
> http://debian.uchicago.edu/debian/dists/bookworm-updates/InRelease is
> expired (invalid since 1d 15h 6min 44s). Updates for this repository will
> not be applied.

Slightly worrisome.

> deb http://debian.uchicago.edu/debian/ bookworm non-free-firmware non-free
> contrib main
> deb-src http://debian.uchicago.edu/debian/ bookworm non-free-firmware
> non-free contrib main

If this mirror continues to be out of date, consider replacing it with
a mirror that's NOT out of date.  Or using one of the round robin
mirror load-balancers, or the deb.debian.org mega-load-balancer.

Re: Address 127.0.1.1

[Greg Wooledge]

On Fri, May 24, 2024 at 08:05:43AM -0400, Paul M Foster wrote:
> Folks:
> 
> In my /etc/hosts file, there's a line:
> 
> 127.0.1.1 yosemite.mars.lan yosemite
> 
> I think Debian put it there.

Correct.  This is the address that will be used if you don't have a
static LAN address.

> Later in the file, I've got:
> 
> 192.168.254.30  yosemite.mars.lan   yosemite

Since you *do* have a static LAN address, you can use this one instead.
(Assuming this address actually *does* get assigned to an interface.)
The 127.0.1.1 address isn't needed in this case.

Re: OpenSMTPD can't parse smarthost

[Greg Wooledge]

On Thu, May 23, 2024 at 07:53:31AM -0400, Paul M Foster wrote:
> Nslookup fails. However, yosemite.mars.lan is in the hosts file and you
> can successfully ping it. It has a fixed (local) IP, which was set in the
> router. I don't understand why nslookup fails when buckaroo knows who
> yosemite is.

nslookup looks *only* in DNS.

If you want a tool that follows the same hostname lookup policies
that programs like "ping" use, there's getent(1).

hobbit:~$ nslookup hobbit
Server: 127.0.0.1
Address:127.0.0.1#53

** server can't find hobbit: NXDOMAIN

hobbit:~$ getent hosts hobbit
127.0.1.1   hobbit.wooledge.org hobbit
hobbit:~$ getent hosts www.debian.org
2603:400a::bb8::801f:3e www.debian.org

Of course, a lot of people just use "ping" for this same purpose.  It's
not ideal, but it works.

hobbit:~$ ping -c1 hobbit
PING hobbit.wooledge.org (127.0.1.1) 56(84) bytes of data.
64 bytes from hobbit.wooledge.org (127.0.1.1): icmp_seq=1 ttl=64 time=0.015 ms

--- hobbit.wooledge.org ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 0.015/0.015/0.015/0.000 ms

Re: Dovecot correct ownership for logs

[Greg Wooledge]

On Sun, May 19, 2024 at 05:15:40PM +0200, Richard wrote:
> Then where does the combination rwx come in here? With read the app knows
> the file is there, with write it writes to the file. Question is, where the
> necessity would be to know the owner of the file or even the kind. The
> logger is supposed to just append text to a file.

Stop trying to reason out WHY things are the way they are.  Just accept it.

You need execute permission on a directory in order to access anything
within that directory.  That's how it is.  That's the decision the
creators of Unix came up with.

In order for a program to write (append) to a file that already exists,
it needs:

 * execute permission on every directory leading up to that file
 * write permission on the file

If the file does NOT already exist, then the program needs to be able to
create it, and in that case, it will need:

 * execute permission on every directory leading up to where the file goes
 * write permission on the final (leaf) directory

File creation, file removal, and file renaming are directory operations,
and they need write (plus execute, of course) permission on the directory.

Modifying an existing file is a file operation, so that needs write
permission on the file (plus execute permission on the directory).

In EVERY case, you always need execute permission on all the parent
directories as well.  This is well-understood, so we usually don't bother
saying it explicitly.

Kudos to whoever you spoke with on the Dovecot list who thought to go
all the way back to first principles on this one.  We got distracted
with all of the other complex ways that this setup could have been
incorrect, and forgot to check one of the most basic ones.

Re: Dovecot correct ownership for logs

[Greg Wooledge]

On Sun, May 19, 2024 at 04:55:09PM +0200, Richard wrote:
> Dovecot expects execution permissions on the directory it writes the logs
> to. Because "Standard POSIX permissions for a non-root process to enter a
> directory." How on earth is that even a thing?

That's how Unix permissions have always worked.  In order to access
a file, you need +x permissions on *all* of the directories leading
up to that file, and then appropriate permissions on the file itself.

If you have read permission on a directory but *not* execute permissions,
then the only thing you can do is read the contents of that directory --
the filenames and their inode numbers.  You cannot stat() the files,
so you can't see who owns them or even what kind of files they are.
Just their names.

If you have execute permission but *not* read permission on a directory,
then you can access the files within the directory, but only if you
already know their names.  You can't read the directory to get their
names.

Likewise, write permission on a directory allows you to rename or unlink
files contained within that directory (because the names are not a
property of the files -- they are part of the *directory*).  You don't
need write permission on a file to unlink it.  Only on the directory.

Re: Markup in mail messages

[Greg Wooledge]

On Sat, May 18, 2024 at 08:26:55PM +0700, Max Nikulin wrote:
> On 17/05/2024 18:10, Greg Wooledge wrote:
> > > On 17/05/2024 10:16, Karl Vogel wrote:
> > > > https://github.com/aaronsw/html2text/ might interest you.  It 
> > > > converts
> > > > (relatively) sane HTML into Markdown.
> > > > 
> > > > I put html2text.py into $HOME/lib and use this to call it:
> > > > 
> > > >   #!/bin/sh
> > > >   # > > >   exec /usr/bin/env python $HOME/lib/html2text.py ${1+"$@"}
> > > >   exit 1
> [...]
> > https://mywiki.wooledge.org/WrapperScript
> > 
> > Short version: "$@" is good enough if your /bin/sh isn't museum-era.
> > ${1+"$@"} works around a bug in some very old shells.
> 
> Thanks. I am unsure if a python2 script from 2011 is consistent with a sh
> expanding "$@" to empty string, but the reason of the construct might be
> just muscle memory or some guide.

It has nothing to do with the program being exec-ed.  The bug is in the
old implementations of /bin/sh.  If you're on Debian, you don't need to
worry about it.  There is *no* version of Debian which has a /bin/sh
which has this bug.  Only legacy commercial Unix systems have it.

> P.S.
> Portable shell section in autoconf manual mentions "${1+"$@"}" issues with
> zsh (the script above requires /bin/sh explicitly):
> https://www.gnu.org/savannah-checkouts/gnu/autoconf/manual/autoconf-2.72/autoconf.html#index-_0022_0024_0040_0022

*sigh* zsh

Well, once again, there is no version of Debian that uses zsh as its
/bin/sh, so you should be OK here.  But if you really want to use the
case $# workaround, I won't say you're wrong.

Re: Dovecot correct ownership for logs

[Greg Wooledge]

On Fri, May 17, 2024 at 08:20:17AM -0400, Henning Follmann wrote:
> No the point is, you are not setting a file path, you are configure dovecot
> to directly write to these files.
> And dovecot is not just one process, there are multiple running as
> different users all trying t write into one file. Race conditions are
> to be expected. Because these options exist does not mean it is  a good
> decision to use them.

This is speculation.  When writing to log files, one normally opens the
file in append mode.  Multiple processes opening a single log file in
append mode, and using atomic write() calls, will not have any locking
or concurrency issues.  It'll just work.

Now, the question is whether Dovecot and Postfix both work this way.  I
don't use those two programs, so I don't know the answer to that.

It has become apparent that nobody on this mailing list has the intimate
technical knowledge of Dovecot and/or Postfix required to assist the OP
with setting up this nonstandard logging configuration.  I would suggest
that the OP should try on a Dovecot or Postfix support list instead.

Re: Markup in mail messages

[Greg Wooledge]

On Fri, May 17, 2024 at 12:43:49PM +0700, Max Nikulin wrote:
> On 17/05/2024 10:16, Karl Vogel wrote:
> >https://github.com/aaronsw/html2text/ might interest you.  It converts
> >(relatively) sane HTML into Markdown.
> > 
> >I put html2text.py into $HOME/lib and use this to call it:
> > 
> >  #!/bin/sh
> >  # >  exec /usr/bin/env python $HOME/lib/html2text.py ${1+"$@"}
> >  exit 1
> 
> I am puzzled by this wrapper. I expect that "$@" is enough here and namely
> {1+"$@"} is redundant. Am I wrong?

https://mywiki.wooledge.org/WrapperScript

Short version: "$@" is good enough if your /bin/sh isn't museum-era.
${1+"$@"} works around a bug in some very old shells.

Re: OT: Top Posting

[Greg Wooledge]

On Wed, May 15, 2024 at 09:46:08AM -0400, Cindy Sue Causey wrote:
> Best as I was able to discern from the Net [0], 72 characters is the
> magic number for line length because 4 extra characters are added to
> both ends when e.g. git processes submissions. Makes good common sense
> to me.
> 
> PS I thought it was 80. Guess it was about those extra 8 characters.

For many decades, there was an industry standard that lines of text
should be up to 80 characters wide.  Punch cards were 80 characters wide,
for example.  I don't know whether punch cards were the *first* place
it appeared, but they're the first I'm aware of.

A lot of the printers from the last century allowed 80 characters
per line on standard US 8.5x11 inch paper.  I'm not sure if teletypes
used 80-column paper, or 133-column paper (green bar), or a mixture.

Later, we got terminals.  A typical ASCII terminal (a physical one, like
a DEC VT-100) is 80x24 characters, or sometimes 80x25.  The 80-character
line standard continued.

When hardware evolved and most of us started using X11 or similar GUI
interfaces, terminal emulators became the norm.  xterm and other software
terminal emulators use an 80x24 window as the default, for compatibility
with physical terminals.

When writing code in most programming languages, there are style guides
that still suggest sticking to 80-character lines whenever possible.
It avoids line wrapping when being read in an 80-character terminal,
and besides that, really long lines of code are harder to read than
shorter lines.

When it comes to email or Usenet, though, the 72-character suggestion
is meant to allow a bit of room for quoting markup.  If I write a
79-character line of text, and then you reply to it with "> " in front,
the resulting 81-character line of text either gets wrapped or truncated.
Limiting yourself to 72-character lines allows a few levels of quoting
before the text becomes unreadable.

This is why the 72-character limit is just a suggestion, not a hard
requirement.  If you write lines that are 74 characters wide, probably
nobody's going to care.  The goal is simply to make it easy to carry
on a conversation.

Re: OT: Top Posting

[Greg Wooledge]

On Tue, May 14, 2024 at 08:16:20PM +0200, Nicolas George wrote:
> Messages in Markdown in the Windows world? I have never seen it.

I can't be sure where they're coming from exactly, but every once in
a while I see messages on debian-user, bug-bash or help-bash which
have extra asterisk characters scattered throughout them (usually
make the code samples break).  The only sensible interpretation I can
come up with for why these asterisks were added is that they're being
placed around text that's supposed to be emphasized/italicized.

When reading the message with the idea that "this might be markdown
text" in mind, it's possible to guess, in most cases, which asterisks
should be removed to render the code samples or terminal session pastes
correct.

Re: OT: Top Posting

[Greg Wooledge]

On Tue, May 14, 2024 at 05:01:31PM +, fxkl4...@protonmail.com wrote:
> how many times has this top post crap been dug up
> don't y'all have any thing better to do

It's never going to stop.  We have a clash of two cultures here.

The first culture are Unix users who grew up with Internet email and
Usenet news.  For people in this culture, there is a well-defined set
of "netiquette" rules -- plain text messages, inline quoting with "> "
citation characters, lines limited to ~72 characters, etc.

For users in this first group, email is often read and composed on a
terminal, or a terminal emulator.  Characters are displayed in a
fixed-width font.  ASCII art is possible, albeit frowned upon as
juvenile.

The second culture are Windows users who grew up with Microsoft products
in their school or workplace.  In this culture, top-posting is the norm,
and inline quoting is nigh impossible.  Messages are often sent in either
HTML or markdown format.  Whole paragraphs are presented as single lines.
Explicit line breaks are only used between paragraphs.

Users in this second group typically use Microsoft Outlook, or a
web-based mail user agent in a graphical environment.  Fonts are
variable-width, and any ASCII art or tables will not align properly.

Now, normally when these cultures clash, we're able to point to the
Debian netiquette guidelines, and move on.

In this particular instance, we've got a person from the second culture
who seems to have no idea that other cultures exist, or that a mailing
list might not adhere to their own expectations.  This person is acting
belligerantly, and will not listen to gentle reminders.

The best course of action in this case is to drop it, but pride can make
people do the wrong things sometimes.

Re: How to run automatically a script as soon root login

[Greg Wooledge]

On Tue, May 14, 2024 at 02:51:17PM +0200, Mario Marietto wrote:
> I've installed the Cloudflare gateway on Debian as a vm because I can't do
> it directly in FreeBSD. But I want to be covered even when I use FreeBSD.
> The script that I wrote forward the Cloudflare "VPN" from Debian to
> FreeBSD,so from outside my IP will be cloudFlared.

Disclaimer: I know nothing about Cloudflare.

So you wrote a bash script.  I will assume this script does what you
want it to.  You type its name to run it, or you have it set up to run
at boot time, or you have it set up to run at login time, or via a
cron job, or via a DHCP dhclient enter/exit hook

Where does the GOTO come in?  Do you think your script does something
internally which mimics a GOTO in some way?  Or that it *should* do that?

Why would you need a GOTO to do whatever networking configuration steps
the script does?  Lacking any knowledge of Cloudflare, I'm imagining
that the script simply performs a sequence of commands, in a linear order,
without any branching or looping or jumping around.

Re: Dovecot correct ownership for logs

[Greg Wooledge]

On Tue, May 14, 2024 at 07:36:17PM +0800, jeremy ardley wrote:
> Postfix is chrooted (usuallly) to /var/spool/postfix

If this is true, then how would a local delivery agent work?  It needs
write access to all users' inboxes, which are either in /var/mail or in
users' home directories.

I could imagine the Postfix SMTP sending/receiving and queue processing
programs being chrooted, but the LDA probably isn't.  Or at least not
chrooted to /var/spool/postfix.

Re: How to run automatically a script as soon root login

[Greg Wooledge]

On Tue, May 14, 2024 at 01:10:05PM +0200, Mario Marietto wrote:
> Your answer does not help me to understand how to use a "structured
> programming / if , while, for, functions" for the specific task that I want
> to achieve.

What task is that?

Re: How to run automatically a script as soon root login

[Greg Wooledge]

On Tue, May 14, 2024 at 08:09:18AM +0200, Mario Marietto wrote:
> Nobody can show a different way,a modern way, for creating my script ? Why
> did I feel so comfortable by recreating the 1960s GOTO statement in Bash ?

I have absolutely no clue what you're trying to do or why you're trying
to do it, but I *promise* you, whatever you think you're doing, you
have NOT recreated a GOTO statement in bash.

You showed a function.  Functions can be called.  This is NOT the same
as issuing a GOTO command, because once the function returns, control
flow resumes from the point where it was called.

Bash (and sh, on which bash is based) explicitly chose not to have a GOTO
statement in its language.  The authors chose instead to use the control
primitives that are collectively known as "structured programming"
(if, while, for, functions).

Re: Dovecot correct ownership for logs

[Greg Wooledge]

On Mon, May 13, 2024 at 10:16:13PM +0200, Richard wrote:
> May 13 20:55:37 mail postfix/local[2824184]: 95BCF1000A9: to=,
> > relay=local, delay=3.2, delays=1.9/0.29/0/1.1, dsn=4.3.0, status=deferred
> > (temporary failure. Command output: lda(user): Error:
> > net_connect_unix(/run/dovecot/stats-writer) failed: Permission denied Can't
> > open log file /var/log/dovecot/error.log: Permission denied )
> 
> This is the content of /var/log/dovecot:
> -rw-r--r--  1 dovecot dovecot0 13. Mai 20:50 debug.log
> -rw-r--r--  1 dovecot dovecot  880 13. Mai 21:21 error.log
> -rw-r--r--  1 dovecot dovecot  40K 13. Mai 21:20 info.log

The first two things that come to mind are AppArmor, and systemd unit
files.

Check to see whether there's an AppArmor profile for this program, or
any lines from AppArmor in dmesg.

If that's not it, look at the systemd unit file(s) that start the
dovecot service(s), if there are any, and see if they're using any of
the directives that restrict the locations the program can access.

Re: How to run automatically a script as soon root login

[Greg Wooledge]

On Mon, May 13, 2024 at 06:06:37PM +0200, Hans wrote:
> Am Montag, 13. Mai 2024, 13:24:17 CEST schrieb Greg Wooledge:
> > On Mon, May 13, 2024 at 07:36:07AM +0200, Richard wrote:
> > > .profile
> 
> Sorry, dumb question: Depending of the shell, the user is using (let's say, 
> he 
> will use bash), can the script not be added into ~/.bashrc?

The context has been snipped out.  The context for this was "OP is trying
to run a command when root logs in".  The method of login was not stated.
First responder said ".profile works for every method of login".  I said
that this is incorrect: it doesn't work for many GUI login setups.

In those same GUI login setups, .bashrc is *also* not read when the
user logs in.  None of the shell startup files are read at all.

All of this is a tangent to the actual problem, though.

> If yes, second dumb question: Coiuld it be ANY script or command? 
> (also running as non-rootuser, like adding "runuser -u myuser 
> command_whatever").

We're several layers deep into an X-Y problem here.  The *actual* problem
is that the system's networking configuration is not correct/complete.

The *workaround* is that the OP is logging in and running commands to
change the networking configuration temporarily.

The question resulting from the workaround (the Y in the X-Y) was "How
can I automate these commands that I keep having to type?"

The proper question should have been "How can I fix my system's networking
configuration permanently?"

Re: How to run automatically a script as soon root login

[Greg Wooledge]

On Mon, May 13, 2024 at 02:03:59PM +0100, Richmond wrote:
> >> sudo xterm -e "echo 1 > hello"

> Yes, but why did it allow me to delete the file? I was not root
> then. Try it.

Because you have write permission on the *directory* that the file is in.

Removing (unlinking) a file is an operation that modifies a directory,
not the file itself.  You don't need write permission on the file.  Just
the directory.

Re: How to run automatically a script as soon root login

[Greg Wooledge]

On Mon, May 13, 2024 at 01:48:25PM +0200, Mario Marietto wrote:
> I wouldn't to login as root automatically,but I've realized that this
> command :
> 
> echo 1 > /proc/sys/net/ipv4/ip_forward
> 
> work only if I'm root. It does not work using sudo. So,in the end I've
> chosen to be root instead of a normal user that can use sudo.

Aha!  Classic X-Y problem.

To do this with sudo, you can use a shell:

sudo sh -c 'echo 1 > /proc/sys/net/ipv4/ip_forward'

However, this particular setting can also be done with sysctl:

sudo sysctl -w net.ipv4.ip_forward=1

Or if you just want the setting to be made permanent, edit the
/etc/sysctl.conf file, find the line that says:

# Uncomment the next line to enable packet forwarding for IPv4
#net.ipv4.ip_forward=1

and remove the # sign in front of net.ipv4.ip_forward=1 and then you
will never have to issue your command manually again.

Re: How to run automatically a script as soon root login

[Greg Wooledge]

On Mon, May 13, 2024 at 07:36:07AM +0200, Richard wrote:
> .profile
> will always be read as soon as the user logs in, no matter how. Through a
> terminal, a GUI, doesn't matter.

That's not correct.  There are many different GUI login setups where
the .profile is never read.

That said, since this thread is specifically about *root* logins, GUI
logins may not be possible.  It depends on which Display Manager and
Desktop Environment are in use.  Many of them explicitly disallow direct
root logins.

So, ultimately it comes down to what the OP actually requires, and
what type of setup they use.  If they only want this thing to happen
when root logs in directly on a console or ssh, then .profile may
indeed be the correct answer.

Re: Bookworm's /etc/mailcap seems to break s-nail

[Greg Wooledge]

On Mon, May 06, 2024 at 02:53:10PM +0200, Jesper Dybdal wrote:
> I use s-nail as my mailx command (selected using the Debian "alternatives"
> mechanism).
> 
> Since I upgraded from Bullseye to Bookworm, s-nail now shows a bunch of
> error messages in connection with viewing messages.  Here is a sample:
> > s-nail: $MAILCAPS: /etc/mailcap: x-scheme-handler/mailto: ignored
> > unknown string/command: u = \\${u//\\"/\\"}
> > s-nail: $MAILCAPS: /etc/mailcap: text/english: ignored unknown
> > string/command: then exec emacsclient --alternate-editor =
> > --display=\\"\\$DISPLAY\\" \\"\\$@\\"

I don't have lines like this in mine.  Then again, I don't have emacs
installed.

The question (one of the questions) is what's putting them there, and I
would guess one of the emacs packages is doing it.

> I have no particular wish to learn about /etc/mailcap.  The only way I've
> found to avoid this is to remove the /etc/mailcap file entirely.

I would think deleting any lines containing "emacs" would be slightly
less invasive.  Obviously, make a backup copy of the file first.

Re: Viewing an an OpenStreetMap tile offline.

[Greg Wooledge]

On Sun, May 05, 2024 at 11:52:32AM -0700, pe...@easthope.ca wrote:
> Hi, is anyone using Gosm or something similar to view OpenStreetMap 
> tiles offline?
> https://wiki.openstreetmap.org/wiki/Gosm
> 
> The instructions under "Downloading and running" yield
> bash: ./gosm: No such file or directory
> 
> "Last Update: 2013-04-26" suggests an ia32 application?
> 
> Is there an alternative application?
> 
> Multiarch is needed in this 64 bit system?
> 
> Other ideas?

Start by running "file gosm".

If this is an i386 program, then yes.  You'll want to enable i386
multi-arch support (there's a wiki page with basic steps), and then
install whatever i386 libraries are needed.  "ldd" can help you figure
those out.

Re: realpath quoting

[Greg Wooledge]

On Sat, May 04, 2024 at 08:22:27AM -0500, Tom Browder wrote:
> $ cat read.raku
> #!/usr/bin/env raku
> my $a = "name with spaces";
> my $b = "name\nwith newline";
> say "file 1: |$a|";
> say "file 2: |$b|";
> 
> And executing it:
> 
> $ ./read.raku
> file 1: |name with spaces|
> file 2: |name
> with newlines|
> 
> With Raku, it's easy to search the directory for the weird file names,
> open them, and use their contents.

You've not really demonstrated anything that can't be done in every other
scripting language.

hobbit:~$ cat foo
#!/bin/bash
a='name with spaces'
b=$'name\nwith newline'
printf 'file 1: |%s|\n' "$a"
printf 'file 1: |%s|\n' "$b"
hobbit:~$ ./foo
file 1: |name with spaces|
file 1: |name
with newline|

hobbit:~$ cat bar
#!/usr/bin/tclsh8.6
set a "name with spaces"
set b "name\nwith newline"
puts "file 1: |$a|"
puts "file 2: |$b|"
hobbit:~$ ./bar
file 1: |name with spaces|
file 2: |name
with newline|

hobbit:~$ cat baz
#!/bin/sh
a='name with spaces'
b='name
with newline'
printf 'file 1: |%s|\n' "$a"
printf 'file 2: |%s|\n' "$b"
hobbit:~$ ./baz
file 1: |name with spaces|
file 2: |name
with newline|


The only part of this that's even *slightly* awkward is loading a literal
newline into a variable in /bin/sh.  And that part drops away and ceases
to be a problem when you read the filename from some kind of input
source (such as a directory).

In real life:

hobbit:~$ mkdir /tmp/x && cd /tmp/x
hobbit:/tmp/x$ touch 'name with spaces' $'name\nwith newline'
hobbit:/tmp/x$ vi foo
hobbit:/tmp/x$ chmod +x foo
hobbit:/tmp/x$ cat foo
#!/bin/sh
for f in *; do
printf 'Next file: |%s|\n' "$f"
done
hobbit:/tmp/x$ ./foo
Next file: |foo|
Next file: |name
with newline|
Next file: |name with spaces|

There's nothing in here that requires an advanced language.  /bin/sh can
do it all perfectly well.  In fact, we haven't even reached the limits
of what /bin/sh can do yet.

hobbit:/tmp/x$ vi foo
hobbit:/tmp/x$ cat foo
#!/bin/sh
printf 'Next file: |%s|\n' *
hobbit:/tmp/x$ ./foo
Next file: |foo|
Next file: |name
with newline|
Next file: |name with spaces|

Is that useful in real life?  Maybe.  Maybe not.  But it's available.

Correct use of quotes and globs solves most of the problems that people
have with sh.

Can it solve "I have to manually paste filenames containing spaces and
punctuation out of a spreadsheet into a shell"?  No, probably not.
But then, what can?  Sometimes, the workflow is what has to change.

Re: realpath quoting

[Greg Wooledge]

On Thu, May 02, 2024 at 10:18:03PM -0700, David Christensen wrote:
> I am unable to find $'string' in the dash(1) man page (?).  As I typically
> write "#!/bin/sh" shell scripts, writing such to deal with file names
> containing non-printing characters is going to baffle me.

Currently, $' quoting is a bash extension.  It's supposed to appear in
some future edition of POSIX, at which point shells like dash will be
required to adopt it (whenever they get around to it).  For now, though,
you should consider it bash only.

Re: realpath quoting

[Greg Wooledge]

On Fri, May 03, 2024 at 12:31:13PM +0800, jeremy ardley wrote:
> My use case is very simple. Give an argument to a program that expects a
> single filename/path.

Then you need to use "$1" with quotes when you reference it.  Simple!

> If you give it an unquoted and unescaped filename it will break parsing the
> args thinking there are many.

Ahhh!  You're not even in the script yet.  You're having trouble *passing
the filename as an argument* from your interactive shell.

The best way to do this is to use tab completion.  The shell should
automatically quote the filename for you, using backslashes.

> When invoking from bash with auto completion the filename will get escaped
> as required. When cutting and pasting into a debugger prompt for args, not
> so.

Ahhh!  The question changed a second time!

I have no idea what you think the shell, or the debugger, should do
about this case.

I would suggest that if you need to use a debugger to track down a bug
in your program, you should use filenames that don't require quoting
when you set up your tests.

Re: realpath quoting

[Greg Wooledge]

On Thu, May 02, 2024 at 07:11:46PM -0700, David Christensen wrote:
> Perhaps Perl and the module String::ShellQuote ?
> 
> 2024-05-02 18:50:28 dpchrist@laalaa ~
> $ touch "name with spaces"
> 
> 2024-05-02 18:50:45 dpchrist@laalaa ~
> $ touch "name with\nnewline"

You didn't create a name with a newline in it here.  You created a name
with a backslash in it.  If you wanted a newline, you would have to use
the $'...' quoting form (in bash).

touch $'name with\nnewline'

> 2024-05-02 19:06:01 dpchrist@laalaa ~
> $ perl -MString::ShellQuote -e 'print shell_quote(@ARGV), "\n"' name*
> 'name with spaces' 'name with\nnewline'

I still insist that this is a workaround that should *not* be used
to try to cancel out quoting bugs in one's shell scripts.  Just write
the shell scripts correctly in the first place.

Re: realpath quoting

[Greg Wooledge]

On Fri, May 03, 2024 at 07:42:20AM +0800, jeremy ardley wrote:
> 
> On 3/5/24 07:29, Greg Wooledge wrote:
> > > The spaces without quotes cause problems with subsequent processing.
> > Then the subsequent processing has bugs in it.  Fix them.
> > 
> > > Can realpath or other utility return a quoted pathname?
> > That would be extremely counterproductive.  Do not look for kludges to
> > work around your script's bugs.  Fix the bugs instead.
> > 
> > Start with<https://mywiki.wooledge.org/Quotes>.
> > 
> 
> You don't see a problem that ls produces quoted filenames and realpath
> doesn't?

Oh Jesus, don't get me started on ls.

We have a whole page on that.  <https://mywiki.wooledge.org/ParsingLs>

Re: realpath quoting

[Greg Wooledge]

On Fri, May 03, 2024 at 06:59:37AM +0800, jeremy ardley wrote:
> I have a need  to get the full path of a file that has spaces in its name to
> use as a program argument
> 
> e.g.
> 
> jeremy@client:~$ ls -l name\ with\ spaces
> -rw-r--r-- 1 jeremy jeremy 0 May  3 06:51 'name with spaces'
> jeremy@client:~$ realpath name\ with\ spaces
> /home/jeremy/name with spaces

Looks good to me.

> The spaces without quotes cause problems with subsequent processing.

Then the subsequent processing has bugs in it.  Fix them.

> Can realpath or other utility return a quoted pathname?

That would be extremely counterproductive.  Do not look for kludges to
work around your script's bugs.  Fix the bugs instead.

Start with .

Re: Zutty fonts - zutty always uses the same font and fontsize

[Greg Wooledge]

On Thu, May 02, 2024 at 09:34:13AM +0700, Max Nikulin wrote:
> On 01/05/2024 21:58, Sirius wrote:
> > 
> > I was right about .Xresources that it is one of the files used for loading
> > settings into the X server, but urxvt looks at .Xdefaults instead.
> 
> It is a bit strange. Applications should not read these files directly.
> Content should be loaded during X session startup, see
> /etc/X11/Xsession.d/30x11-common_xresources
> 
> After modification of .Xresources it is necessary to invoke xrdb(1).

I'm not sure about rxvt-unicode, but the original rxvt definitely
worked that way.  This was part of the lightweight design of rxvt.
The author didn't want the bloat involved in reading the X resource
database, so he chose to read the source files directly.

According to :

  RESOURCES (available also as long-options)

  Note: 'rxvt --help' gives a list of all resources (long options)
  compiled into your version. If compiled with internal Xresources
  support (i.e. rxvt -h lists .Xdefaults) then rxvt accepts application
  defaults set in XAPPLOADDIR/Rxvt (compile-time defined: usually
  /usr/lib/X11/app-defaults/Rxvt) and resources set in ~/.Xdefaults,
  or ~/.Xresources if ~/.Xdefaults does not exist.


The corresponding section of the rxvt-unicode man page (in Debian 12)
is a bit confusing to me:

   You can set and change the resources using X11 tools like xrdb. Many
   distribution do also load settings from the ~/.Xresources file when X
   starts. urxvt will consult the following files/resources in order, with
   later settings overwriting earlier ones:

 1. app-defaults file in $XAPPLRESDIR
 2. $HOME/.Xdefaults
 3. RESOURCE_MANAGER property on root-window of screen 0
 4. SCREEN_RESOURCES property on root-window of the current screen
 5. $XENVIRONMENT file OR $HOME/.Xdefaults-
 6. resources specified via -xrm on the commandline

It says you can use xrdb, but then lists the places it looks, and that
list does not include xrdb(?).  I don't understand what this means.

Re: Zutty fonts - zutty always uses the same font and fontsize

[Greg Wooledge]

On Wed, May 01, 2024 at 02:31:49PM +0200, Sirius wrote:
> zutty is kind of only necessary when you want something *really*
> lightweight and you do not need to worry about UTF-8. Just writing this
> means a trip down memory lane and back to configuring CTWM on old Sun 5
> workstations back in the 90's. If Debian still packages it, look for rxvt
> instead, or use xterm. Both are well tried and well tested for when you
> want something .. dated. ;)

The original rxvt is no longer packaged in Debian, as far as I can see.
There's rxvt-unicode, which is what I use, which has most of the same
look and feel as rxvt, but is substantially larger.

Between xterm and rxvt-unicode you should have most of your "basic
no-frills terminal" needs met by one or the other.

Re: Debian 12.5 i386 sudo returns "Illegal instruction"

[Greg Wooledge]

On Thu, Apr 25, 2024 at 09:54:17AM -0400, Vic tor wrote:
> On a fresh installation of Debian 12.5, i386 I receive "Illegal instruction"
> when executing sudo. Is there any way to debug and workaround this; should I
> take this to another list as a bug?
> 
> This is on a Soekris net5501 powered by an AMD Geode LX which is the only
> oddball factor. I've been running Debian on these guys since version 8 without
> any problem.

https://www.debian.org/releases/stable/i386/release-notes/ch-information.en.html#i386-is-i686

  Debian's support for 32-bit PC (known as the Debian architecture i386)
  now no longer covers any i586 processor. The new minimum requirement
  is i686. What this means that the i386 architecture now requires the
  "long NOP" (NOPL) instruction, while bullseye still supported some
  i586 processors without that instruction (e.g. the "AMD Geode").

  If your machine is not compatible with this requirement, it is
  recommended that you stay with bullseye for the remainder of its
  support cycle.

Re: youtube-dl blocked?

[Greg Wooledge]

On Wed, Apr 24, 2024 at 12:27:22PM -0700, Fred wrote:
> If you type yt-dlp --help you get a large list of options.
> yt-dlp --update will get you the very latest version.  (Must be root).

-U, --updateCheck if updates are available. As yt-dlp
has been installed via apt, you should use
that to update.  If you're on a stable
release, also check backports.

Re: youtube-dl blocked?

[Greg Wooledge]

On Wed, Apr 24, 2024 at 11:26:09PM +0800, Bret Busby wrote:
> Okay - my apology - at
> https://github.com/ytdl-org/youtube-dl/blob/master/ChangeLog
> is
> 
> "
> dstftw
> release 2021.12.17
> 
> version 2021.12.17

So don't use that.

The Debian package youtube-dl is NOT actually youtube-dl any more.  It
is a transitional package that brings in yt-dlp instead.

hobbit:~$ dpkg -s youtube-dl | grep -e transitional -e Depends
Depends: yt-dlp
Description: download videos from YouTube and other sites (transitional package)

The yt-dlp package is version 2023.03.04-1.  It's 13 months old.

Re: youtube-dl blocked?

[Greg Wooledge]

On Wed, Apr 24, 2024 at 10:31:44PM +0800, Bret Busby wrote:
> The latest version of youtube-dl , makes it too old to try to use now; if
> you can get it working with youtube, good luck to you.
> 
> An unmaintained package, that is three years since last updated, for
> accessing web sites on the World Wide Web?
> 
> H.

The youtube-dl package in Debian 12 is a transitional package which
brings in yt-dlp (version 2023.03.04-1 currently).

Whether that's too old to be usable is a good question, but it's
definitely not "three years since last updated".

Re: youtube-dl blocked?

[Greg Wooledge]

On Tue, Apr 23, 2024 at 11:15:17PM -0300, Markos wrote:
> The site https://ytdl-org.github.io/youtube-dl/download.html
> 
> is blocked?

Nope.  Works for me.

Debian@IBMx3550

[Greg]

Hi there,

I got refurb IBM x3550 M3 7944 server and I'm a bit lost. Is there any 
Linux/Debian software (some gui would be nice) to monitor fan speed, 
temperatures, voltages, disks.. ?


Thanks in advance for any help
Greg

Re: tbird troubles

[Greg Wooledge]

On Tue, Apr 16, 2024 at 02:21:27PM -, Curt wrote:
> Have you tried *closing* one of the two windows, *quitting* the
> remaining one, and then restarting your bird?

In his original message, he claimed that closing one window makes the
other one also close.

I asked *how* he was closing them, and he said that he gets the same
result whether he uses the WM's close button, or the application's Exit
menu choice.

Re: tbird troubles

[Greg Wooledge]

On Mon, Apr 15, 2024 at 10:59:25AM -0400, e...@gmx.us wrote:
> On 4/15/24 10:01, gene heskett wrote:
> > On 4/15/24 09:09, Greg Wooledge wrote:
> > > On Mon, Apr 15, 2024 at 08:28:24AM -0400, gene heskett wrote:
> > > > For the last 2 or 3 reboots, when launching t-bird, I get 2 copies of 
> > > > the
> > > > gui stacked on top of each other. I can move them separately to 2 
> > > > separate
> > > > workspaces, and both appear to work for some definition of working, but
> > > > quitting one actually quits both.
> > > 
> > > How do you launch it?  Are you clicking something?  Are you 
> > > DOUBLE-clicking
> > > something?
> > > 
> > A single click on the name from the internet section of the xfce menu.

I'm wondering whether Gene's mouse might be physically failing, and
sending multiple click events when he presses the button once.  This
is one of the possible failure modes for mouse buttons.

> Try running "thunderbird" from a terminal emulator and see what happens.

Yes, that's a reasonable thing to try.

To see whether the mouse button might be misbehaving, Gene could try
running xev, and slowly clicking the (left) mouse button inside the
xev window.  There should be exactly one press event, and one release
event, each time the button is clicked, regardless of how long it's
held down.

Re: tbird troubles

[Greg Wooledge]

On Mon, Apr 15, 2024 at 08:28:24AM -0400, gene heskett wrote:
> For the last 2 or 3 reboots, when launching t-bird, I get 2 copies of the
> gui stacked on top of each other. I can move them separately to 2 separate
> workspaces, and both appear to work for some definition of working, but
> quitting one actually quits both.

How do you launch it?  Are you clicking something?  Are you DOUBLE-clicking
something?

How do you quit one of them?  Do you click an X or similar widget in
the window manager decorations, or do you use something like "File ->
Exit" from a menu?

Re: config files - newline possible?

[Greg Wooledge]

On Thu, Apr 11, 2024 at 08:42:20PM +0200, Hans wrote:
> in my case it is the config freom from bootcdwrite, which is bootcdwrite.conf.


says:

This file will be sourced as shell file.

So, you may use any valid "shell" (presumably sh) syntax, including
backslash-newline for continuation.

Re: problem with live usb booting

[Greg Wooledge]

On Thu, Apr 11, 2024 at 01:30:46PM +, sarath wrote:
> dear debian
> 
> I have created live usb with debian-live-12.5.0-amd64-standard.iso using tool 
> Ventoy-1.0.95. When tried to booting it is ended with command line options. 
> please help me to the next step

It's not clear to me what you mean.  Was there an *error* message?  If so,
what does it say?

If you simply mean "I expected a graphical interface, and instead I got
a text console login prompt", that's because you used the -standard image
which has a minimalist set of packages, equivalent to what you would get
if you installed Debian normally, and un-selected the desktop environment
option, and only left "Standard" selected.

If you want a graphical interface, you'll need a different image.

[Sid] Nouveau: only one monitor after 6.6.15 to 6.7.9 upgrade

[Greg]

Hi there,

I have two HP Z30i connected to Nvidia GeForce GTX 670. After last 
upgrade I'm able to use only one monitor.


When running linux-image-6.7.9:

# dmesg | grep nouveau | cut -b 16-
nouveau :01:00.0: vgaarb: deactivate vga console
nouveau :01:00.0: NVIDIA GK104 (0e4090a2)
nouveau :01:00.0: bios: version 80.04.19.00.0f
nouveau :01:00.0: fb: 2048 MiB GDDR5
nouveau :01:00.0: DRM: VRAM: 2048 MiB
nouveau :01:00.0: DRM: GART: 1048576 MiB
nouveau :01:00.0: DRM: TMDS table version 2.0
nouveau :01:00.0: DRM: MM: using COPY for buffer copies
snd_hda_intel :01:00.1: bound :01:00.0 (ops 
nv50_audio_component_bind_ops [nouveau])

[drm] Initialized nouveau 1.4.0 20120801 for :01:00.0 on minor 0
fbcon: nouveaudrmfb (fb0) is primary device
nouveau :01:00.0: vgaarb: VGA decodes changed: 
olddecodes=io+mem,decodes=io+mem:owns=io+mem

nouveau :01:00.0: [drm] fb0: nouveaudrmfb frame buffer device
# xrandr
Screen 0: minimum 320 x 200, current 2560 x 1600, maximum 16384 x 16384
DVI-I-1 connected 2560x1600+0+0 (normal left inverted right x axis y 
axis) 641mm x 400mm

   2560x1600 59.97*+
   1920x1200 59.95
   1920x1080 60.00
   1600x1200 60.00
   1680x1050 59.88
   1280x1024 60.02
   1440x900  59.90
   1280x800  59.91
   1280x720  60.00
   1024x768  60.00
   800x600   60.32
   640x480   59.94
   720x400   70.08
DVI-D-1 disconnected (normal left inverted right x axis y axis)
HDMI-1 disconnected (normal left inverted right x axis y axis)
DP-1 disconnected (normal left inverted right x axis y axis)

When running linux-image-6.6.15:

# dmesg | grep nouveau | cut -b 16-
nouveau :01:00.0: vgaarb: deactivate vga console
nouveau :01:00.0: NVIDIA GK104 (0e4090a2)
nouveau :01:00.0: bios: version 80.04.19.00.0f
nouveau :01:00.0: fb: 2048 MiB GDDR5
nouveau :01:00.0: DRM: VRAM: 2048 MiB
nouveau :01:00.0: DRM: GART: 1048576 MiB
nouveau :01:00.0: DRM: TMDS table version 2.0
nouveau :01:00.0: DRM: DCB version 4.0
nouveau :01:00.0: DRM: DCB outp 00: 01000f02 00020030
nouveau :01:00.0: DRM: DCB outp 01: 02000f00 
nouveau :01:00.0: DRM: DCB outp 02: 08011f82 00020030
nouveau :01:00.0: DRM: DCB outp 03: 02022f62 00020010
nouveau :01:00.0: DRM: DCB outp 04: 04833fb6 0f420010
nouveau :01:00.0: DRM: DCB outp 05: 04033f72 00020010
nouveau :01:00.0: DRM: DCB conn 00: 1030
nouveau :01:00.0: DRM: DCB conn 01: 00020131
nouveau :01:00.0: DRM: DCB conn 02: 00010261
nouveau :01:00.0: DRM: DCB conn 03: 2346
nouveau :01:00.0: DRM: MM: using COPY for buffer copies
snd_hda_intel :01:00.1: bound :01:00.0 (ops 
nv50_audio_component_bind_ops [nouveau])

[drm] Initialized nouveau 1.4.0 20120801 for :01:00.0 on minor 0
nouveau :01:00.0: vgaarb: VGA decodes changed: 
olddecodes=io+mem,decodes=io+mem:owns=io+mem

fbcon: nouveaudrmfb (fb0) is primary device
nouveau :01:00.0: [drm] fb0: nouveaudrmfb frame buffer device
# xrandr
Screen 0: minimum 320 x 200, current 5120 x 1600, maximum 16384 x 16384
DVI-I-1 connected 2560x1600+2560+0 (normal left inverted right x axis y 
axis) 641mm x 400mm

   2560x1600 59.97*+
   1920x1200 59.95
   1920x1080 60.00
   1600x1200 60.00
   1680x1050 59.88
   1280x1024 60.02
   1440x900  59.90
   1280x800  59.91
   1280x720  60.00
   1024x768  60.00
   800x600   60.32
   640x480   59.94
   720x400   70.08
DVI-D-1 connected 2560x1600+0+0 (normal left inverted right x axis y 
axis) 641mm x 400mm

   2560x1600 59.97*+
   1920x1200 59.95
   1920x1080 60.00
   1600x1200 60.00
   1680x1050 59.88
   1280x1024 60.02
   1440x900  59.90
   1280x800  59.91
   1280x720  60.00
   1024x768  60.00
   800x600   60.32
   640x480   59.94
   720x400   70.08
HDMI-1 disconnected (normal left inverted right x axis y axis)
DP-1 disconnected (normal left inverted right x axis y axis)

Any suggestions?
Greg

Re: Debian 12.5: pigz 2.6-1 fails with error message (Upstream issue 111)

[Greg Wooledge]

On Tue, Apr 02, 2024 at 06:34:43PM -0400, Jeffrey Walton wrote:
> On Tue, Apr 2, 2024 at 6:24 PM Chung Jonathan  wrote:
> >
> > Dear Franco Martelli, dear Thomas Schmitt,
> >
> > Sorry for the potential duplication. This mail should now also go to the 
> > list.
> >
> > I believe I found the problem which was on my side. I do have libz.so.1.3, 
> > since I manually compiled grpc on my machine and this also uses a newer 
> > version of zlib appearently. So this is not a Debian problem but rather 
> > specific to my setup. A clean install in a VM indeed works as expected.
> > Do you still think a bug report is worth it?
> 
> Your problem is one that plagues Linux. You compile and link against
> one version of a library, and then you runtime link against another
> version. This should have been fixed for users a long time ago, but
> the folks responsible leave users to suffer it. I consider it a
> security bug since essentially random libraries are being loaded at
> runtime.
> 
> To fix the problem yourself, add an RPATH to your LDFLAGS when
> building your program:
> 
> -Wl,-rpath=/path/to/expected/libz -Wl,--enable-new-dtags
> 
> The loader will encounter the RPATH when loading your executable, and
> load the correct library for your program.

I've run into a variant of this issue myself.  I had compiled an
upstream version of Tcl, which builds a shared library named libtcl8.6.so
in the lib/ subdirectory of the --prefix used for ./configure, where
the default value of --prefix is /usr/local.

This places the shared library in /usr/local/lib which happens to be in
the default set of paths used by ldconfig and ld.so.  Which in turn
means that the locally built library gets used when running Debian's
packaged version of Tcl, taking priority over the version installed in
/usr/lib/x86_64-linux-gnu/ or whatver arch-specific directory is used.

In my case, the solution was to build my local version of Tcl with a
different --prefix.  Then there's nothing dropped into /usr/local/lib
and there's no conflict with the system's packages.

Of course, this is a particularly subtle problem that most users are not
going to be aware of.  It's specific to packages that build part of
themselves as a shared library, which immediately makes most programs
immune to it.  But when it *does* affect you, it can be tricky to
figure out what's happening.

It sounds like the OP's pigz issue was of a similar nature.  If this is
the case, then filing a Debian bug report isn't going to be helpful,
unless it's done as a sort of documentation for anyone else who runs
into the same problem in the future.

Re: Bookworm: Where are the ImageMagick binaries other than `convert`?

[Greg Wooledge]

On Mon, Apr 01, 2024 at 10:06:40PM -0400, e...@gmx.us wrote:
> On 4/1/24 21:37, Christian Gelinek wrote:
> > Hi,
> > 
> > I have ImageMagick installed, but only the `convert` binary is in my path.
> > 
> > Other binaries like `magick` are not. Where can I find them,
> 
> In Synaptic, if you get the properties of an installed package one of the
> tabs is "installed files".  You can find out where (or whether) those things
> are actually installed.

The command-line equivalent is "dpkg -L", to list the files that belong
to an installed package.

In the specific case of imagemagick, things get a little bit weird:

hobbit:~$ dpkg -L imagemagick-6.q16 | grep bin/
/usr/bin/animate-im6.q16
/usr/bin/compare-im6.q16
/usr/bin/composite-im6.q16
/usr/bin/conjure-im6.q16
/usr/bin/convert-im6.q16
/usr/bin/display-im6.q16
/usr/bin/identify-im6.q16
/usr/bin/import-im6.q16
/usr/bin/mogrify-im6.q16
/usr/bin/montage-im6.q16
/usr/bin/stream-im6.q16

And these are pointed to by symlinks in the "alternatives" system:

hobbit:~$ ls -l /usr/bin/convert
lrwxrwxrwx 1 root root 25 Feb 12 15:15 /usr/bin/convert -> 
/etc/alternatives/convert*
hobbit:~$ ls -l /etc/alternatives/convert
lrwxrwxrwx 1 root root 24 Feb 12 15:15 /etc/alternatives/convert -> 
/usr/bin/convert-im6.q16*

In any case, there is no command named "magick".

Re: Debian 11 PHP 7.4 – Mysql 8 - Can’t get Mysqli_connect to work

[Greg Wooledge]

On Fri, Mar 29, 2024 at 11:49:06AM +0100, Bernard wrote:
> Hi to Everyone,
> 
> The text quoted below has already been sent to the list, 2-3 days ago,
> someone had replied to it (but the message has been lost, I no longer see it
> on the list. I had replied again, which reply disappeared too.)
> So, I want to say again that the errors shown in the text below (S instead
> of $, ` inst of ') are not errors that I made in the php script, which
> scripts I write using old vi (vim). This was due to the fact that some parts
> of my messages here were typed using LibreOffice and parts were copy/pasted
> here.

That was something you wrote in a private reply to me, not to the list.

Re: making Debian secure by default

[Greg Wooledge]

On Thu, Mar 28, 2024 at 03:23:48PM -0400, Lee wrote:
> so apparently somebody else has done a threat analysis and decided
> apparmor is the appropriate mitigation strategy?

*An* appropriate mitigation strategy.  Not "the".

There are many, many layers.

Re: making Debian secure by default

[Greg Wooledge]

On Thu, Mar 28, 2024 at 05:23:36PM +0100, Florent Rougon wrote:
> Did anyone try 'mesg n' here? I tried:
> 
> 
> $ mesg n
> $ mesg; echo $?
> is n
> 1
> 
> Broadcast message from root@hostname (pts/1) (Thu Mar 28 16:48:13 2024):
> 
> pouet

You can't stop root from writing to your terminal.  Root has write
privileges on all devices.

The purpose of mesg is to allow *other regular users* to send you
messages, or not.  People have focused so much on "wall" in this
thread, but wall is usually used by root, or by the OS itself, to
send broadcast notices of major events like impending reboots.

The more common tool for users to talk to each other on their terminals
is write(1).  Or if you wanted to have a conversation, there's talk(1).
Or rather, there's supposed to be talk(1).  I have a POSIX man page
for it, but not a Debian one, and the program itself doesn't appear to
be installed.  Maybe it's in a separate package.

I have write(1) from the bsdextrautils package.  There is a talk package
but I haven't installed it.

Re: making Debian secure by default

[Greg Wooledge]

On Thu, Mar 28, 2024 at 01:30:32PM +, Andy Smith wrote:
> I'm just not sure that you'll find any "hardening" guide that will
> specifically say "disable writing to your terminal as there might be
> a bug in a binary that is setgid tty" before yesterday's reveal that
> there is such a bug in "wall".
> 
> The more general advice to audit every setuid/setgid binary is more
> likely to be present.
[...]
> If the maintainer of util-linux doesn't agree, then the next thing
> I'd try is a bug against the Debian Administrator's Handbook:
> 
> https://www.debian.org/doc/manuals/debian-handbook/
> 
> This has a chapter on security, so possibly it would be appropriate
> to mention "m,esg n" there.

A more proactive endeavor would be to document known best practices
on the wiki.  A quick search found a couple pages that might serve
as starting points:

https://wiki.debian.org/SecurityManagement
https://wiki.debian.org/Hardening  -- says it's for package maintainers

Anyone who is serious about such a project probably has a long road ahead
of them.

Re: variables in bash

[Greg Wooledge]

On Thu, Mar 28, 2024 at 10:37:25AM +0100, Hans wrote:
> What is the difference (if any) between the following two variables in a 
> shellfile in bash:
> 
> 1. mypath=/home/user1/Tools/
> 2. mypath="/home/user1/Tools/"

They are the same.  The quotes are optional here, because your assignment
doesn't contain any whitespace.

The quotes would be required if you had something like:

mypath="/mnt/c/Program Files/"

In any case, the assignment is the easy part.  Most people get this
part right.  Where they screw up is here:

> and $mypath

Whenever[1] you use "$mypath", you'll want double quotes around it.
Otherwise, it'll get split into multiple words at whitespace, and
will also be subject to filename expansion.  You don't want that.

mypath="/mnt/c/Program Files/"
if ! test -d $mypath; then ...  # wrong

The example above will *not* work, because the space in the middle
of $mypath's value will cause the test command to receive two
separate words, instead of one word.  It needs to be quoted:

mypath="/mnt/c/Program Files/"
if ! test -d "$mypath"; then ...# right

> Is this in bash the same? Do other shells (sh, zsh, whatever) handle these 
> two 
> different?

Most quoting rules are the same in all sh-derived shells, including the
rules I talked about here.

As you dive deeper into shell scripting, you'll find some cases where
the rules change a bit across different shells, but so far you're still
in the shallow end.

[1] There are some exceptions, but for now, go with the simplest rule:
"When in doubt, double-quote it."

Re: Debian 11 PHP 7.4 – Mysql 8 - Can’t get Mysqli_connect to work

[Greg Wooledge]

On Thu, Mar 28, 2024 at 10:36:01AM +0100, Bernard wrote:
> But I've found more problems, concerning $_REQUEST, $_GET...
> 
> The old way that I used 11 yrs ago no longer works :
> 
> $nom = S_GET [‘nom’] ;
> 
> no longer operates with php 7.4. This code is simply ignored. S_REQUEST,
> $_POST do not work either.

You mentioned $_GET and then you wrote S_GET.

You also have Unicode curly quote marks there, not ASCII apostrophes.

It's impossible for us to tell whether your PHP code is actually broken,
or whether you *retyped* it with errors for your email.

Re: debian12: something destroys /etc/network/interfaces at boot

[Greg Wooledge]

On Tue, Mar 26, 2024 at 06:33:42PM +0100, Steffen Dettmer wrote:
> I changed a gateway on a remote site using /etc/network/interfaces by
> changing gateway. However, at reboot some old gateway IP reappears.

So then the question is *which* of the many different subsystems is in
use to set the system's default gateway.  It might be coming from /e/n/i
or from NetworkManager or from systemd-networkd or others.

> root@site4-nas:~# ls -l /etc/network/interfaces
> -rw-r--r-- 1 root root 117 Mar 26 18:19 /etc/network/interfaces
> root@site4-nas:~# grep gateway /etc/network/interfaces
> gateway 192.168.2.43

See, that's not useful.  That's not how this file is structured.  It's
NOT just a series of independent lines.

We would need to see the entire /e/n/i file to know which interface
that gateway definition is associated with, and so on.

A gateway definition on an interface that isn't managed by /e/n/i (ifupdown)
will do nothing at all.  For example, you might have an eno1 definition
which includes a gateway line, but which does *not* have an "auto eno1"
line to activate it -- in which case the interface might be managed by
NetworkManager instead, or something else.

Re: seeding /dev/random from a security key

[Greg Wooledge]

On Mon, Mar 25, 2024 at 06:09:02PM -0400, e...@gmx.us wrote:
> On 3/25/24 17:27, Andy Smith wrote:
> > The thread covers how to make rngd feed /dev/random from a OneRNG in
> > Debian 12, but it is no longer possible to tell if that does
> > anything useful.
> 
> If not from devices like this, from where does Debian get its randomness?

random(4) (i.e. "man 4 random") gives a basic introduction to the topic,
if you have manpages-dev installed.

Re: $USER vs. $LOGNAME and the EnvironmentVariables wiki page

[Greg Wooledge]

On Mon, Mar 25, 2024 at 08:48:04PM +0100, Patrice Duroux wrote:
> Hi,
> 
> 1. Using CodeSearch, it is not clear to me when to use one or the other.

Your original Subject: header mentions $USER and $LOGNAME so I assume
you're asking about these.

$LOGNAME is the standard variable which is set by the login(1) program.
Every process in a standard login session should have access to this.
For other login sessions that don't use login(1), the rules may differ,
but see below.

Additionally, crontab(5) documents that cron sets LOGNAME, so all of
your cron jobs should also have access to it.

$USER is the old BSD variable which serves the same purpose.  Most of
the subsystems in Linux (including logins performed by ssh(1) and by
Display Managers) will set both LOGNAME *and* USER, in order to provide
the expected working environment for users from various backgrounds
(and to programs written by developers from various backgrounds).

If you're writing a new program today and wondering which one to use,
$LOGNAME should be the way to go.  Unless you want your program to run
on every old Unix/BSD system in the world -- then you should check for
both of them, LOGNAME and then USER, and use whichever one you find first.

Re: trying to parse lines from an awkwardly formatted HAR file ...

[Greg Wooledge]

On Sat, Mar 23, 2024 at 02:05:06PM -0500, Albretch Mueller wrote:
> Actually, in order to deX-Y it in case anyone can offer any help, it
> is more like "I want an index of all the books which have ever been
> written/published" in order to read all of them ;-)

First of all, you will not achieve this goal.  It is not possible for
a human to read every book that has ever been written.  You'll die
before you can even finish a tiny fraction of them.

So, let's say you have a more realistic goal: you want a list of all the
books written by Charles Dickens.

I tried to figure out how to get this out of archive.org but it looks
like their documentation doesn't match their web page.  I started at
 which shows how to
get a list of "items" which all share a common "parent".  I figure
an author might be a reasonable parent.  So then the next question is
how to get the author ID for Charles Dickens.

Next I went to

which tells me I should perform a search on their front page, and
then on the result page, click something called "Media List".

This is where it all falls apart for me.  I can't find a "Media List"
thing to click on.

The documentation also mentions an "ABOUT" that I should be able
to click on to get an Identifier.  Well, that's not a thing I could
find either.  There's an ABOUT link in the top menu bar, which goes to
 which is clearly not what the documentation
was talking about.

All this is far too much of my time wasted trying to help some random
person with an off-topic question on debian-user, so... good luck.

Re: trying to parse lines from an awkwardly formatted HAR file ...

[Greg Wooledge]

On Sat, Mar 23, 2024 at 11:55:04AM -0400, Greg Wooledge wrote:
> On Sat, Mar 23, 2024 at 09:54:05AM -0500, Albretch Mueller wrote:
> >  1) That HAR file is not properly formatted. Instead of
> > "attribute":value pairs in the standard way, they have used front
> > slash + quote pairs (instead of just quotes) erratically all around
> > the file. That is why you can't use jq.
> 
> That is not what I see in the file which I pasted here.

Further investigation:

https://google.com/search?q=what+is+a+HAR+file

  https://www.keycdn.com/support/what-is-a-har-file
  Jan 12, 2023 — A HAR file is primarily used for identifying
  performance issues, such as bottlenecks and slow load times, and page
  rendering problems.

  https://en.wikipedia.org/wiki/HAR_(file_format)
  The HTTP Archive format, or HAR, is a JSON-formatted archive file
  format for logging of a web browser's interaction with a site.
  ...
  This document was never published by the Web Performance Working Group
  and has been abandoned.

So, putting these together, it looks like you are taking a file that
was intended to be used for diagnosing browser/network performance
issues, and attempting to use this in place of a downloadable index
of documents from archive.org.

Furthermore, whatever method you are using to *create* this HAR file
is questionable, since apparently you aren't even getting a properly
formatted file in the end.

This tells me we're deep inside an X-Y problem.  The original goal is
possibly something like "I want an index of all the books about this
Greek dude".  Maybe start from there, and see what answers you get.

Re: trying to parse lines from an awkwardly formatted HAR file ...

[Greg Wooledge]

On Sat, Mar 23, 2024 at 09:54:05AM -0500, Albretch Mueller wrote:
>  a) using a chromium-derived browser, which can be used to dump the
> HAR file log of the network back and forth, go, e. g.:
>   https://en.wikipedia.org/wiki/Anaxagoras
>  b) click on the link that says: "Works by or about Anaxagoras" (at
> Internet Archive)
>  c) on the archive.org page, select "texts" and "always available"
> (meaning text which is public domain, he died 25 centuries ago)
>  d) then to produce the HAR file, go:
>  d.1) More Tools > Developer Tools;
>  d.2) click on "Network" tab;
>  d.3) Filter: GET
>  d.4) check: "Preserve Log"
>  d.5) scroll down the page all the way to make the client-server back
> and forth cascade
>  d.6) save the network log as HAR file to then open and eyeball it!

This is incomprehensible to me.  What the hell is d.5 supposed to be?
Even if I close the Shift-Ctrl-I window, and Ctrl-R to reload the page,
and then reopen Shift-Ctrl-I, and click the down-arrow-in-a-dish icon
whose tooltip says "Export HAR..." all I get in the resulting file
is this:

hobbit:~$ cat Downloads/archive.org.har 
{
  "log": {
"version": "1.2",
"creator": {
  "name": "WebInspector",
  "version": "537.36"
},
"pages": [],
"entries": []
  }
}hobbit:~$ 

Do you have one of these HAR files in a *DIRECTLY DOWNLOADABLE URL*?
Something that doesn't take 12 manual steps that are impossible to
perform?

Or can you *attach* one to a message to this mailing list?  Make sure
it's small.

>  1) That HAR file is not properly formatted. Instead of
> "attribute":value pairs in the standard way, they have used front
> slash + quote pairs (instead of just quotes) erratically all around
> the file. That is why you can't use jq.

That is not what I see in the file which I pasted here.

Re: Root password strength

[Greg Wooledge]

On Tue, Mar 19, 2024 at 03:49:06PM +, debian-u...@howorth.org.uk wrote:
> Dan Ritter  wrote:
> > Check whether you are running ssh:
> > 
> > /sbin/service ssh status
> 
> It's not called ssh; it is sshd
> Also nowadays it's more usual to say
> 
>  $ systemctl status sshd

On Debian, the systemd service name for openssh-server is "ssh", not
"sshd".  However, Debian offers an *alias* named "sshd" which allows
people to type your command and still get a meaningful result.

However, it should be noted that "ssh" is the actual service name, which
matters if you're going to do something like creating a drop-in override.
Those need to be done with the correct name instead of the alias name.

Re: Root password strength

[Greg Wooledge]

On Tue, Mar 19, 2024 at 05:42:55PM +0300, Jan Krapivin wrote:
> The root user's password should be long (12 characters or more) and
> impossible to guess. Indeed, any computer (and a fortiori any server)
> connected to the Internet is regularly targeted by automated connection
> attempts with the most obvious passwords. [...]

For most people, this really isn't a concern, because they either don't
run an ssh server at all, or they use the default sshd_config which does
not allow root logins.

The only time you need to worry about this is if you:

 * Run an ssh server, AND
 * Accept ssh connections from the public Internet, AND
 * Have changed the sshd_config file to allow ssh root logins.

Re: After installing no access to the installed system.

[Greg Wooledge]

On Mon, Mar 18, 2024 at 03:24:14PM +0100, Thomas Schweikle wrote:
> Package: Debian installer
> Version: As on Debian live-CD/DVD for Debian 12.5
> Severity: critical

Note that you sent this email to the debian-user list, not to the bug
tracking system.

> 6. For User and Passwort enter
> Full name: demo Demo
> Username: de-de
> Password 1st: start123
> Password 2nd: start123
> 7. Click install
> 8. Wait until the installer finishes and reboots into this newly installed
> system
> 9. Try to login with the credentials given above:
> User: de-de
> Password: start123
> 
> The newly installed system just tells: unknown user or password, user or
> password wrong. You wont be able to login.

I wonder if it's the hyphen character.  Maybe the installer transforms
that into an underscore, or omits it entirely?  That's just a guess.

Anyway, try logging in as "dede" or "de_de", just to see if one of those
works.  Otherwise, you'll need to boot in rescue mode (or any equivalent
of your choice), and look at the /etc/passwd and /etc/shadow files.
See what happened.

Re: Bookworm Networking Issues

[Greg Wooledge]

On Sun, Mar 17, 2024 at 08:46:26PM +0100, Marco Moock wrote:
> Am 17.03.2024 um 16:54:27 Uhr schrieb David:
> 
> > Can anybody suggest how to get the networking running?
> 
> You have to tell us what doesn't work in your network.
> 
> Also show the output of
> ip a
> cat /etc/resolv.conf

I have a feeling everyone's over-thinking this.  I suspect what the OP
wants is the *literal command* they should type.

Unfortunately, without knowing the contents of /etc/network/interfaces
we can't give the literal command.  You'd have to know the name(s) of
the network interfaces that are defined.  Then, for each interface, you
would run an "ifup" command.

For example, on my current machine, the network interface is named "eno1".
To bring this interface up, if it's not already up, I would run:

ifup eno1

Of course, there's also a desire to ensure that the network interfaces
are correctly brought up when you boot.  Therefore, the ultimate test is
to reboot the machine.  If the interfaces come up when you boot, then
things are probably configured correctly.  If they don't, then you have
a problem to solve.

Re: shellcheck, bashism's and one liners.

[Greg Wooledge]

On Sun, Mar 17, 2024 at 10:57:43AM -0500, Nate Bargmann wrote:
> What errors do you get if you use sh instead of bash?

He's not getting any errors.  His script actually works for his current
inputs.  He was just getting warnings from shellcheck, which is an
external script validation tool.

One of the warnings is harmless in this context.  He's doing something
that *looks* like a common newbie mistake, but actually isn't, and the
reason he's doing it is out of his control (design of apt-get).

The other warning is a valid one, because what he's doing won't work
in the general case, where filenames contain whitespace or globbing
characters.  It works fine with "naive" filenames (alphanumeric plus
a very limited set of punctuation, such as . _ - characters), but
doesn't generalize.


On Sun, Mar 17, 2024 at 11:14:56PM +0700, Max Nikulin wrote:
> On 17/03/2024 16:25, Tim Woodall wrote:
> > args() { echo a b c d; }
> > count() { echo $#; }
> > count $(args)
> 
> args() { printf '%s\0' a b c d; }
> args | xargs -0 sh -c 'count() { echo $#; }; count "$@"' sh-count
> 
> It would be easier in the case of script file instead of shell function. An
> assumption is that all arguments may be passed through command line.

Tim's assumption here is that he can write a function which emits a
stream of whitespace-separated words, and use this safely in an unquoted
command substitution.

count $(args)

I'm guessing "count" is a stand-in for something more complex, but $(args)
is pretty much exactly what he wants to do in his real script.

The problem is that this works *brilliantly* with inputs that are
heavily restricted to a specific set of characters, and fails *utterly*
if the inputs do not conform to that limitation.  There is no middle
ground, and there is no way to fix it up.  Once your inputs take off
their training wheels, you have to throw this script away and rewrite
it from the ground up.

That's why shellcheck gives warnings about this kind of thing.  (Well,
one of many reasons.)

Re: Bookworm Fasttrack and Virtualbox

[Greg Wooledge]

On Sun, Mar 17, 2024 at 12:35:33PM +0100, Miguel A. Vallejo wrote:
> Well... it seems my brain can't distinguish Bookworm from Bullseye.

It's not just you.  The use of three "b" names in a row (buster,
bullseye, bookworm) was in my opinion a poor decision.  I've taken
to calling the releases by their numbers (10, 11, 12) instead of
their codenames to avoid confusion wherever possible.

Re: shellcheck, bashism's and one liners.

[Greg Wooledge]

On Sun, Mar 17, 2024 at 09:25:10AM +, Tim Woodall wrote:
> I have this one-liner (which works but shellcheck doesn't like the
> quoting)
> 
> idxsrc="$( newest_file $( APT_CONFIG=${APT_CONFIG} apt-get indextargets 
> --format '$(FILENAME)' 'Identifier: Packages' ))"
> 
> SC2016: Expressions don't expand in single quotes, use double quotes for that.
> SC2046: Quote this to prevent word splitting.

I can't say that I blame it.  I don't like that quoting either.

However, the thing that *it* doesn't like isn't the same as the thing
that *I* don't like.

It's complaining about '$(FILENAME)' which is a questionable design
choice by the authors of apt-get.  Not much to be done about that.

I'd complain about  newest_file $(cmd)  instead.  It looks like you're
running a command which returns a bunch of filenames, and you want to
select one of the names from this bunch.  Right?

This only works when none of the filenames contain any whitespace or
globbing characters.  Otherwise, there's no way to know which sets of
characters constitute a single filename.  Is "a b c d" one filename,
or two filenames, or three, or four?  There's no way to tell.

> The first is easy enough to avoid by using backslash instead. But the
> second I can't see how to fix as a one-liner.

Oh, I see.  It actually *did* complain about the same thing that I
complained about.  I didn't understand at first that these were two
separate warnings.

> I can make shellcheck happy by doing it like this:
> 
> mapfile -t idxpackages < <( APT_CONFIG=${APT_CONFIG} apt-get indextargets 
> --format \$\(FILENAME\) 'Identifier: Packages' )
> idxsrc="$( newest_file "${idxpackages[@]}")"

Ah, so apt-get returns one filename per line, and you're splitting the
stream on newlines?  I suppose that works well enough in practice, for
the output of apt-get.  It's not too likely that any of your packages
will contain filenames with newlines in them.

In any case, this is *definitely* better than your first command, which
splits on *all* whitespace, not just newlines, and additionally performs
globbing.  If we ignore the possibility of filenames with newlines,
then this fixes all of the issues I can see.

> I have a number of other places where I'm relying on a variable
> containing a number of space separated items that I DO want word
> splitting and so the shellcheck warning is incorrect and I either
> suppress it or find a fix similar to the above.

All such cases fail when one of your "words" may contain whitespace
or globbing characters.

> In almost all other cases, the space separated items cannot, even in
> theory, contain a rogue space, so suppressing the warning is fine

Famous Last Words™.

Re: logcheck(1) in bookworm 12.5 /etc/logcheck/logcheck.logfiles.d/syslog.logfiles

[Greg Wooledge]

On Thu, Mar 14, 2024 at 11:25:52AM -0700, John Conover wrote:
> 
> Email from logcheck(1) contains:
> 
> E: File could not be read: /var/log/syslog
> E: File could not be read: /var/log/auth.log
> 
> which do not exist in bookworm 12.5.

You'll want to install rsyslog, or something equivalent, to get
human-readable text log files.  Otherwise, there's just the systemd
journal.

The logcheck package has a "Suggests" for rsyslog, but not a hard
dependency.

Re: strange time problem with bullseye

[Greg Wooledge]

On Thu, Mar 07, 2024 at 02:33:05PM -0500, Roy J. Tellason, Sr. wrote:
> On Thursday 07 March 2024 09:02:44 am Teemu Likonen wrote:
> > systemctl status systemd-timesyncd.service
> 
> This got me some interesting results:
> 
> ● systemd-timesyncd.service - Network Time Synchronization
>Loaded: loaded (/lib/systemd/system/systemd-timesyncd.service; enabled; 
> vendor preset: enabled)
>   Drop-In: /lib/systemd/system/systemd-timesyncd.service.d
>└─disable-with-time-daemon.conf
>Active: inactive (dead)
> Condition: start condition failed at Wed 2024-02-14 16:17:31 EST; 3 weeks 0 
> days ago
>└─ ConditionFileIsExecutable=!/usr/sbin/VBoxService was not met
>  Docs: man:systemd-timesyncd.service(8)
> 
> Hmm.

Are you running that on a virtualbox client, or a virtualbox host?

In any case, you might find it interesting to read the unit file in
question ("systemctl cat systemd-timesyncd.service").  It looks like
you've got one of the slightly older kind, where the service is always
installed, but is prevented from running if any of several different
programs is found.

Re: Hyphen-minus passwd

[Greg Wooledge]

On Thu, Mar 07, 2024 at 06:59:47PM +0100, Nicolas George wrote:
> ~ $ perl -e 'print crypt("-password", "\$6\$username\$"), "\n"'
> $6$username$FCvGwi21H/uVp89BtnZHWQsL.vZKajZ3lRbfB7Jnjr2C.5qBgx7TB3Ul3PbcyCIArts/C2lfQgYOLp418oH7C0

hobbit:~$ openssl passwd -6 -salt username -- -password
$6$username$FCvGwi21H/uVp89BtnZHWQsL.vZKajZ3lRbfB7Jnjr2C.5qBgx7TB3Ul3PbcyCIArts/C2lfQgYOLp418oH7C0

Looks like you want the -- to separate options from non-option arguments,
where the only non-option argument is "-password".  What threw me for a
few moments was that "-salt username" is a single option with argument.
I wasn't expecting "username" to be the salt.  It looked like a non-option
argument at first.

Re: strange time problem with bullseye

[Greg Wooledge]

On Thu, Mar 07, 2024 at 08:31:16AM -0500, gene heskett wrote:
> So I purged ntpsec and re-installed chrony which I had done once before with
> no luck but this time timedatectl was stopped and it worked!
> 
> Now, how do I assure timedatectl stays stopped on a reboot?

Which version of Debian is this?  I'm guessing it's fairly recent,
because ntpsec is fairly recent.

In the most recent version or two, systemd-timesyncd is a separate
package, and it cannot coexist with chrony (they both provide the
"time-daemon" virtual package).  So, if this is Debian 12 (maybe 11
also, dunno about older), then when you installed either ntpsec or
chrony, it should have removed the systemd-timesyncd package.

You should be able to verify that the systemd-timesyncd package is
removed.

In some older versions of Debian, systemd-timesyncd was part of the
systemd package, and was always installed, even if you installed ntp
or chrony.  In these versions, the systemd unit file for timesync
had checks for the existence of the binaries belonging to ntp, chrony
and openntpd, and would prevent timesync from running if any of those
was found.

I don't remember which version did which thing.

And of course, if you are not actually running Debian, then all bets are
off.  You're on your own with Armbian, Raspbian, etc.

Re: strange time problem with bullseye

[Greg Wooledge]

On Wed, Mar 06, 2024 at 08:33:37PM -0500, gene heskett wrote:
> no place in the ntpsec docs, nor the chrony docs
> does it show the ability to slam the current time into the SW clock on these
> arm systems at bootup's first access time.

Traditionally, this was done by the ntpdate command, which was in the
ntpdate package.

On older Debian releases, you would install both of these (ntp and
ntpdate); ntpdate would run first, slamming the clock, and then ntp
would run second, to keep the clock in sync.

A few releases ago, ntpdate was deprecated, and its slamming functionality
was absorbed into the ntp package, as long as ntp is started with the -g
option.

   -g, --panicgate
   Allow the first adjustment to be big. This option may appear an
   unlimited number of times.

   Normally, ntpd exits with a message to the system log if the offset
   exceeds the panic threshold, which is 1000 s by default. This
   option allows the time to be set to any value without restriction;
   however, this can happen only once. If the threshold is exceeded
   after that, ntpd will exit with a message to the system log. This
   option can be used with the -q and -x options. See the tinker
   configuration file directive for other options.

With ntpsec replacing ntp in Debian 12, the same options apply.  By default,
Debian runs ntpsec with the -g option, to allow the clock to be slammed
at boot time.

hobbit:~$ ps -ef | grep ntpd
ntpsec   854   1  0 Feb17 ?00:01:17 /usr/sbin/ntpd -p 
/run/ntpd.pid -c /etc/ntpsec/ntp.conf -g -N -u ntpsec:ntpsec
greg  3947371138  0 21:34 pts/000:00:00 grep ntpd

Your claims that "no place in the ntpsec docs ... show the ability to
slam the current time" are simply false.

Re: strange time problem with bullseye

[Greg Wooledge]

On Wed, Mar 06, 2024 at 05:56:29PM -0500, gene heskett wrote:
> On 3/6/24 12:42, Greg Wooledge wrote:
> > On Wed, Mar 06, 2024 at 12:31:46PM -0500, Roy J. Tellason, Sr. wrote:
> > >  sudo timedatectl set-ntp true
> > 
> > But *don't* do that if you're using some other NTP program instead of
> > systemd-timesyncd.

> Are you saying that both chrony and ntpsec, which are fully ntp
> client/server ack the docs are worthless to timedatectl?

I'm saying "don't turn on systemd's NTP thing if you're using a different
NTP thing".

Roy's instructions failed to take into account that many of us are
already using a different NTP implementation, besides systemd's.

Re: strange time problem with bullseye

[Greg Wooledge]

On Wed, Mar 06, 2024 at 12:31:46PM -0500, Roy J. Tellason, Sr. wrote:
> Mine shows:
> 
>   Local time: Wed 2024-03-06 12:09:44 EST
>   Universal time: Wed 2024-03-06 17:09:44 UTC
> RTC time: Wed 2024-03-06 17:20:53
>Time zone: America/New_York (EST, -0500)
>  Network time on: yes
> NTP synchronized: no
>  RTC in local TZ: no
> 
> How do I get the RTC to agree with the right time?

"hwclock -w" to copy the system clock to the hardware clock (RTC).  This
should also be done during shutdown, but it doesn't hurt to do it now.


On Wed, Mar 06, 2024 at 07:36:11PM +0200, Teemu Likonen wrote:
> To get operating system's clock have accurate time it needs to be
> synchronized with network time servers via network time protocol (NTP).
> Systemd has that feature. Turn in on with
> 
> sudo timedatectl set-ntp true

But *don't* do that if you're using some other NTP program instead of
systemd-timesyncd.  Unfortunately, timedatectl does not know about other
NTP programs, and won't report which one you're using.  You'll have
to find that out yourself.

Re: 404 Not Found Error Problem

[Greg Wooledge]

On Wed, Mar 06, 2024 at 08:21:11AM -0500, Stephen P. Molnar wrote:
> Not Found
> 
> The requested URL was not found on this server.
> Apache/2.4.57 (Debian) Server at abnormal.att.net Port 80
> 
> I've installed WebMO a number of times and have not encountered this
> particular problem before.

Are you "abnormal.att.net"?  Or at least pretending to be that host
in your error messages?

Or is your web browser going to that host, when you expected it to go
to localhost or something?

Re: strange time problem with bullseye

[Greg Wooledge]

On Wed, Mar 06, 2024 at 07:37:09AM +0200, Teemu Likonen wrote:
> It seems that you have solved the problem but here is another hint.
> "timedatectl" is a good high-level tool for querying and adjusting time
> settings. Without command-line arguments it prints a lot of useful info:
> 
> $ timedatectl
>Local time: ke 2024-03-06 07:33:00 EET
>Universal time: ke 2024-03-06 05:33:00 UTC
>  RTC time: ke 2024-03-06 05:33:00
> Time zone: Europe/Helsinki (EET, +0200)
> System clock synchronized: yes
>   NTP service: active
>   RTC in local TZ: no
> 
> See "timedatectl -h" or manual page for more info.

This is a great hint, but be warned that it doesn't quite know about
NTP services other than systemd-timesyncd.  If you're running ntpsec,
for example, it'll simply say:

System clock synchronized: yes
  NTP service: n/a

Re: strange time problem with bullseye

[Greg Wooledge]

On Tue, Mar 05, 2024 at 08:28:49PM +0800, hlyg wrote:
> Thank Greg Wooledge!
> 
> zhou@debian:~$ date
> Wed 06 Mar 2024 04:07:02 AM CST
> zhou@debian:~$ date -u
> Tue 05 Mar 2024 08:07:07 PM UTC
> 
> above is from deb11 for i386, it's correct

OK, and your time zone is 20 hours ahead of UTC, it appears.

> zhou@debian:~$ date
> Tue 05 Mar 2024 08:13:23 PM CST
> zhou@debian:~$ date -u
> Tue 05 Mar 2024 12:13:27 PM UTC
> 
> above is from deb11 for amd64, it's wrong, utc lag behind by 4 hours

Now this is odd-looking.  In this instance, your time zone is 4 hours
*behind* UTC instead of 20 hours ahead.  Which makes it off by exactly
one whole day.

Also, it *looks* like your i386 instance wrote UTC to the system clock,
and then your amd64 instance read that as local time.  You can see that
the 8:07:07 PM from the first instance is quite close to the 8:13:23 PM
from the second.

> Windows shall not cause problem, i rarely use Windows

The question isn't how often you use it, but whether you booted it in
between the two instances above.  Probably not, I suppose.

> i don't know if ntp is running, what's default configuration by deb11 amd64
> installer?

There is no "default".  Or rather, there are lots of defaults.  It's not
useful to ask about defaults.  Ask about what you have.

These are the packages that provide time-daemon on Debian 11:

systemd-timesyncd
openntpd
ntp
chrony

If one of those is installed and running, it should set your clock from
Internet sources (assuming it's configured reasonably, and you have
Internet access).

But more importantly, you need to check whether your Debian instances are
using local time or UTC for the real time clock, because it *looks* like
the i386 one is using UTC and the amd64 is not.

Check your /etc/adjtime files.

I'm also extremely curious why two different systems report "CST" with
two wildly different offsets from UTC.  What does
"ls -ld /etc/localtime" give on your systems?  Are they both the same?

Re: strange time problem with bullseye

[Greg Wooledge]

On Wed, Mar 06, 2024 at 02:47:06AM +0800, hlyg wrote:
> my newly-installed deb11 for amd64 shows wrong time,  it lags behind correct
> time by 8 hours though difference between universal and local is ok.

Run the commands "date" and "date -u" and show us the output.

Then tell us what you think the output should have been.

> but my deb11 for i386 on same machine shows correct time. i installed it
> long time ago

You have more than one operating system on this machine, then.  Are these
two Debian instances the *only* systems, or are there others?  Is Windows
one of them?

When multi-booting, it's important that all of the operating systems on
the machine agree on whether the real time clock is set to UTC, or to
local time.  For a long time, the conventional approach was to use local
time if you had to multi-boot with Windows (because Windows insisted on
it), or UTC if you only boot Linux-based systems.  I don't know how
Windows deals with the real time clock in modern times.

For comparison, please run "date" and "date -u" on the "deb11 for i386"
instance.

In particular, you're looking to see whether the "date -u" command
reports correct UTC time, and you're looking for what time zone the "date"
command uses.

If your UTC time is right but your time zone is wrong, then you need to
change your time zone.  On Debian, you do this by running
"dpkg-reconfigure tzdata".

If your UTC time is wrong, but it's off by exactly the amount that your
local time differs from UTC, then it's possible that one or more of your
multi-boot operating systems disagree on whether the real time clock is
set to UTC or local time.  Pick one, and then configure all of your
operating systems to use that.

If your UTC time is just wrong, with no obvious reason for it, then the
next question is whether you're running NTP.  And if not, why not (e.g.
this machine is on an isolated network or something).  Most computers
should be using NTP (Debian offers several choices for this), which will
keep the system clock reasonably correct, unless the hardware is failing.

Re: how to wiki

[Greg Wooledge]

On Tue, Mar 05, 2024 at 11:23:59AM -0500, Paul M Foster wrote:
> On Tue, Mar 05, 2024 at 04:15:20PM +, fxkl4...@protonmail.com wrote:
> 
> > how do i access the debian wiki
> > https://wiki.debian.org/
> > all i get is
> > 
> > 
> > 
> > 
> > Forbidden
> > 
> > You are not allowed to access this!
> > 
> 
> Check your firewall, proxies or other items which could restrict your
> access. I'm in the southeastern U.S. and am easily able to access that URL
> with no problems.

It's not a client side issue.  It's a server side block.  The wiki
admins will have to look at it and decide how to handle it.

Re: how to wiki

[Greg Wooledge]

On Tue, Mar 05, 2024 at 04:15:20PM +, fxkl4...@protonmail.com wrote:
> how do i access the debian wiki
> https://wiki.debian.org/
> all i get is
> 
> 
> 
> 
> Forbidden
> 
> You are not allowed to access this!

>From :

Q: Can I rename my account?

  A: Yes, just login and click on Settings -> Preferences and edit the Name
 field. If you cannot login, then just reset your password first. Your
 existing edits will be attributed to the new account name.

Q: Access to wiki.debian.org is blocked with 403 Forbidden

  Please mail w...@debian.org with your IP address.

Re: bash parameter expansion "doesn't like" dots?

[Greg Wooledge]

On Tue, Mar 05, 2024 at 11:24:11AM +0900, John Crawley wrote:
> ^ worked as a negator in dash character classes up to Bullseye though, so 
> something has changed recently. That's what my web searching failed to find...

It looks like dash doesn't have up-to-date documentation on its changes.
There's a ChangeLog file in the upstream Git repository's top level
directory[1] (shipped as changelog.gz in the Debian package), but the most
recent entry in it is dated 2014-11-17.

We might *guess* that this change was made to make dash more strict
about POSIX minimalism (removing extensions), but without documentation
we can't do more than guess about motives.

[1] https://git.kernel.org/pub/scm/utils/dash/dash.git/tree/

Re: bash parameter expansion "doesn't like" dots?

[Greg Wooledge]

On Tue, Mar 05, 2024 at 10:49:34AM +0900, John Crawley wrote:
> On 05/03/2024 05:27, David Wright wrote:
> > Which shell also matters. The OP appears to be using ^ to negate,
> > but ! has the advantage that it will be understood in bash and dash.
> 
> I think ^ has been deprecated recently. I failed to find a reference on the 
> web just now though.

POSIX specifies that ! is the negation character in glob ranges, largely
because ^ used to be a synonym for | in the old Bourne shell (for the
benefit of keyboards that didn't have a convenient | character).

The use of ^ as a glob negation is a bash extension.  It's nice for
people who may not even realize that they're supposed to be using !
because they learned regular expressions first.

So, ^ isn't "deprecated".  It's just not portable to sh.

Re: a couple rpi problems

[Greg Wooledge]

On Mon, Mar 04, 2024 at 11:41:07PM +, ghe2001 wrote:
> 1) The 5, pi5.slsware.lan, keeps sending me email saying, 
> 
> "*** SECURITY information for pi5 ***" 

So, "pi5" appears to be your hostname.

> "pi5 : Mar  4 15:40:14 : root : unable to resolve host pi5: Name or service 
> not known"
> 
> I have no idea why it's complaining or what's bent.  

It can't resolve its own hostname.  You're probably missing a line in
your /etc/hosts file.

Re: Wifi - unable to connect. [solved]

[Greg]

On 2/26/24 18:52, Kamil Jońca wrote:
[...]


What if:
network = {
  ssid="ssid"
  key_mgmt=WPA-EAP
  eap=PEAP
  identity="uid"
  phase2="auth=MSCHAPV2"
  mesh_fwding=1
  password="pas"
  }


Bingo! Dzięki wielkie, ułatwiłeś mi życie.

Regards
Greg

resolv.conf (was Re: electrons/the Internet [racism redacted])

[Greg Wooledge]

On Mon, Mar 04, 2024 at 12:36:54PM -0800, David Christensen wrote:
> I believe Debian rewrites /etc/resolv.conf on every boot.

This is not correct.  It's *partly* correct if you ignore a lot of
complicating factors.

Short version: read .

Long version follows:

If you have a static network interface configuration, defined in
/etc/network/interfaces, with no DHCP client, no VPN stuff going on,
etc. then your /etc/resolv.conf will not be changed.  You can edit the
file and put whatever you want in it, and it'll remain as you wish it
to be.

Unfortunately, almost *nobody* has a setup like this any more.

In a more typical environment, you get your IP address via DHCP, which
means you're running a DHCP client daemon.  Most DHCP client daemons
will rewrite the /etc/resolv.conf file every time they refresh their
DHCP lease.  This may indeed happen at boot time, but it'll also happen
a couple times a day during normal operations.

So, a simple instruction like "edit /etc/resolv.conf" is no longer
possible.  Even worse, there's no single *alternative* either.  You can't
even say "do ___ instead".

To put the correct values into your /etc/resolv.conf file nowdays, you
have to select a *strategy*.  You need to find an indirect way to put
the right content into some *other* place, in such a way that it will
eventually find its way into /etc/resolv.conf every time the file is
rewritten.  And there are *lots* of strategies that will work, so you
can't even say "obviously this one is best".  Life is not that simple.

Or, you could use chattr +i to make the /etc/resolv.conf file immutable,
so DHCP clients and other programs cannot overwrite it.

Either way, you take ownership of whatever strategy you decide to use,
together with its pros and cons.  You'll have to understand that on *this*
system, you went with *this* strategy, and remember where to put your
changes, and how to make them.  Or at the very least, you'll need to be
*aware* of all the strategies you've got in play on all of your systems,
and know how to identify which one is in use on any given system.

All of this is documented on 
but it's a virtual certainty that nobody in this thread will read that
wiki page and select a strategy and implement it and be happy.  Instead,
we will have another hundred-message argument, in which half the
participants will have no idea what the issue is (but will chime in loudly
anyway), and the second half will simply attack whatever strategies the
third half have selected.

And in another month or two, we'll do it all again.

Re: missing development package?

[Greg Wooledge]

On Mon, Mar 04, 2024 at 11:56:54AM +, debian-u...@howorth.org.uk wrote:
> thyme after thyme  wrote:
> > *  debian.list
> > # Debian Stable.
> > deb http://deb.debian.org/debian bookworm main contrib non-free
> > non-free-firmware
> > deb http://security.debian.org/debian-security bookworm-security main
> > contrib non-free non-free-firmware
> > #deb-src http://deb.debian.org/debian bookworm main contrib non-free
> > non-free-firmware
> 
> Does the # character at the start of the deb-src line matter?

Yes, very much so.  It's the comment character, and it means that this
line is not to be used.

Re: “Secure Connection Failed” Error in Firefox

[Greg Wooledge]

On Sun, Mar 03, 2024 at 12:26:20PM -0300, Marcelo Laia wrote:
> When accessing the website https://gontijoonibus.gontijo.com.br/ on Firefox 
> Android (on my smartphone), the site is accessed normally. However, when 
> attempting to access this site on the desktop, Debian Firefox-ESR version 
> 115.8.0esr (64-bit), the following error occurs:
> 
> 
> Secure Connection Failed
> An error occurred during a connection to gontijoonibus.gontijo.com.br.
> The page you are trying to view cannot be displayed because the authenticity 
> of the received data could not be verified.
> Please contact the website owners to inform them of this problem.
> 
> Learn more…

For the record, Google Chrome gives:

This site can’t be reached

The webpage at https://gontijoonibus.gontijo.com.br/ might be temporarily
down or it may have moved permanently to a new web address.

ERR_HTTP2_PROTOCOL_ERROR

Re: DNSSEC status of deb.debian.org

[Greg Wooledge]

On Sun, Mar 03, 2024 at 02:06:00PM +, Andy Smith wrote:
> On Sun, Mar 03, 2024 at 09:39:42AM +, Andre Rodier wrote:
> > I was checking the Debian domain, and noticed that it is DNSSEC compliant.
> > 
> > However, when I check "deb.debian.org", the DNS validation fails.
> 
> Things in the debian.org domain are responding correctly with DNSSEC
> but deb.debian.org is a CNAME to debian.map.fastlydns.net, and
> *that* domain doesn't (yet?) use DNSSEC.
> 
> $ delv deb.debian.org
> ; fully validated
> deb.debian.org. 3600IN  CNAME   debian.map.fastlydns.net.
> deb.debian.org. 3600IN  RRSIG   CNAME 8 3 3600 20240405180549 
> 20240225172415 59788 debian.org. 
> YnRgyoBEdwn9PHKTN9pIHNp+VyY+J0hripSOOV7feEsJmgfJwwslnsTR 
> pC0QTkKZQlNflC2sPGqAc5/sKSHHGkHdKYemVCH7IcDTKOZ6wilVUlvT 
> zumWhTZDk+ntLoptwmDblI6emnj8z8wimiFuyGv3+bU16RbdzdFvMdQI 
> Ys9Ldyz6eQSMMyD58OwpiwDxFWjns92iUb05VB+yLeVeFwQ9uvJW1lZa 
> oASmDhoyNijntU9UjA6h/Bzx6ZJvLHlE
> 
> ; unsigned answer
> debian.map.fastlydns.net. 30IN  A   146.75.74.132

In addition to all of that, please note that deb.debian.org uses SRV
records instead of regular A or  records.  This is explained
(not fully) on http://deb.debian.org/ if you care to read it.

Re: where are the crontab files in Trixie?

[Greg Wooledge]

On Tue, Feb 27, 2024 at 10:12:11PM -0500, The Wanderer wrote:
> On 2024-02-27 at 14:09, Gary Dale wrote:
> > as does find / -name crontab
> 
> Invoked how? In particular, as which user?
> 
> Assuming that the crontab files are actually named literally 'crontab'
> with no extra characters (perhaps by being stored one per directory), my
> guess would be that this is because /var/spool/cron/crontabs is not
> world-executable, and therefore most users won't be able to list its
> contents. If you run that 'find' command as root, or as a user which is
> in the group that owns the directory, you may see that the files show
> up.
> 
> (If they aren't literally named just 'crontab' verbatim, then you'd also
> need to specify wildcards etc. in the find arguments, in order for it to
> recognize them as being a valid match.)

The only file named "crontab" is /etc/crontab.

Per-user crontabs which live in /var/spool/cron/crontabs are named for
their owner.

hobbit:~$ sudo ls /var/spool/cron/crontabs
greg

If you really want to find where the files live, and you didn't happen
to already know (approximately) where they are, and if you haven't been
reading this mailing list thread, then you could try reading cron(8):

NOTES
   cron  searches  its  spool  area (/var/spool/cron/crontabs) for crontab
   files (which are named after accounts in /etc/passwd);  crontabs  found
   are  loaded  into  memory.  Note that crontabs in this directory should
   not be accessed directly - the crontab command should be used to access
   and update them.

This isn't hard to find.  Seriously.  Even if you tried crontab(1) first,
it's in there too:

DESCRIPTION
   crontab  is  the  program used to install, deinstall or list the tables
   used to drive the cron(8) daemon in Vixie Cron.   Each  user  can  have
   theirowncrontab,andthoughthesearefiles   in
   /var/spool/cron/crontabs, they are not intended to be edited directly.

The only place it *isn't* is crontab(5), but hey, two out of three ain't
bad, as someone once sang.

Re: where are the crontab files in Trixie?

[Greg Wooledge]

On Tue, Feb 27, 2024 at 12:52:33PM -0700, Charles Curley wrote:
> On Tue, 27 Feb 2024 14:13:49 -0500
> Jeffrey Walton  wrote:
> 
> > > The debian wiki suggests that the handling of cron/anacron is
> > > evolving.  
> > 
> > That sounds like a euphemism for "being killed off" by Systemd and
> > its timers.
> 
> These days cron and anacron are run as services/timers by systemd.
> 
> root@hawk:~# systemctl list-units '*cron*'
>   UNITLOAD   ACTIVE SUB DESCRIPTION   
>   
>   cron.serviceloaded active running Regular background program 
> processing daemon
>   anacron.timer   loaded active waiting Trigger anacron every hour
>   nextcloudcron.timer loaded active waiting Run Nextcloud cron.php every 5 
> minutes

Systemd timers are designed to replace crontabs, but that's not what
cron.service is.  cron.service runs an actual cron daemon.

hobbit:~$ systemctl status cron
● cron.service - Regular background program processing daemon
 Loaded: loaded (/lib/systemd/system/cron.service; enabled; preset: enabled)
 Active: active (running) since Sat 2024-02-17 20:45:06 EST; 1 week 2 days >
   Docs: man:cron(8)
   Main PID: 789 (cron)
  Tasks: 1 (limit: 18738)
 Memory: 21.9M
CPU: 5.275s
 CGroup: /system.slice/cron.service
 └─789 /usr/sbin/cron -f

hobbit:~$ ps -fp 789
UID  PIDPPID  C STIME TTY  TIME CMD
root 789   1  0 Feb17 ?00:00:01 /usr/sbin/cron -f

I don't foresee real cron going away any time soon.  If systemd wants to
create an alternative to it, that's fine, but people know cron, they
like cron, and they *trust* cron.  Systemd timers don't have any of those
benefits yet.

Re: where are the crontab files in Trixie?

[Greg Wooledge]

On Tue, Feb 27, 2024 at 10:15:59AM -0500, Gary Dale wrote:
> I'm running Debian/Trixie on an AMD64 system. I have an old wifi adapter
> that Linux has problems with that works once I run:
> 
> /usr/sbin/modprobe brcmfmac
> echo 13b1 0bdc > /sys/bus/usb/drivers/brcmfmac/new_id
> 
> However when I add those lines to the root's crontab using # crontab -e as
> 
> @reboot /usr/sbin/modprobe brcmfmac
> @reboot echo 13b1 0bdc > /sys/bus/usb/drivers/brcmfmac/new_id
> 
> the second line fails. I get an e-mail stating "/bin/sh: 1: cannot create
> /sys/bus/usb/drivers/brcmfmac/new_id: Directory nonexistent"

Having two separate @reboot lines might run them both in parallel,
rather than sequentially.  It might be better to combine them into
one shell command, or one script.

Something like this, perhaps:

@reboot /usr/sbin/modprobe brcmfmac && echo 13b1 0bdc > 
/sys/bus/usb/drivers/brcmfmac/new_id

Or put the commands into a shell script, then run the script from crontab.

Re: running Jami in Trixie - possible locale issue

[Greg Wooledge]

On Tue, Feb 27, 2024 at 08:48:27AM -0500, Gary Dale wrote:
> > You've got three different locales mentioned here:
> > 
> > iu_CA.UTF-8
> > en_GB
> > en_CA.UTF-8
> > 
> > Either generate the two that you're missing, or stop using them.
> 
> I'm trying to stop using them. That's the point. How do I get rid of them?
> They show up no matter how many times I reconfigure my locales.

OK.  Start from the beginning.

How do you login to this computer?  SSH?  Text console?  Graphical
display manager?  (Which one?)

Do you run a desktop environment?  If so, which one?  Do you run some
command to start it, like startx, or is it started by your DM login?

If you're using a text console login or an ssh login, what shell do
you use?  Bash, zsh, tcsh, ...?

If you're using an ssh login, what do your locales look like on the
client system, before you ssh to the Debian system?

If you don't *normally* use a text console login, try doing one.  Press
Ctrl-Alt-F2, and then login on tty2, and see what your locales are.
In this login session, you *only* have variables that are set up by PAM
and your login shell.  If you see the undesired variables here, then
you know it's coming from one of those two places.

If you don't see the undesired variables in the text console login,
then they're coming from somewhere else -- from the client system, if
this is an ssh login, or from your desktop environment, etc.

Re: How to upgrade the GLIBCXX and GLIBC to the specific version

[Greg Wooledge]

On Tue, Feb 27, 2024 at 08:08:47AM -0500, Gremlin wrote:

> > > On Tue, Feb 27, 2024 at 06:51:13AM +, Diego Luo （罗国雄） wrote:
> > > > I am using the Raspberry Pi 4B with the Raspbian OS “Linux
> > > > raspberrypi 5.15.61-v8+ #1579 SMP PREEMPT Fri Aug 26 11:16:44
> > > > BST 2022 aarch64 GNU/Linux”, which is Debian based OS.

> He is most likely using armv7 and that comes with its own issues, ie cpu
> type and floating point (hard/soft, neon and simd).  aarch64 much easier to
> build on.

It looks like he's using aarch64.

Re: How to upgrade the GLIBCXX and GLIBC to the specific version

[Greg Wooledge]

On Tue, Feb 27, 2024 at 06:51:13AM +, Diego Luo （罗国雄） wrote:
> Hi,
> 
> Would you pls help give tips about how to upgrade the GLIBCXX and GLIBC to 
> the specific version (GLIBCXX_3.4.29, GLIBC_2.34) on Debian?
> 
> I am using the Raspberry Pi 4B with the Raspbian OS “Linux raspberrypi 
> 5.15.61-v8+ #1579 SMP PREEMPT Fri Aug 26 11:16:44 BST 2022 aarch64 
> GNU/Linux”, which is Debian based OS.
> When running a SW I met the problem missing the required versions of GLIBCXX 
> and GLIBC, with the details below.
> root@raspberrypi:/home/bitmap_overlap/linux-aarch64# 
> ./blueriver_bitmap_streamer
> ./blueriver_bitmap_streamer: /lib/aarch64-linux-gnu/libstdc++.so.6: version 
> `GLIBCXX_3.4.29' not found (required by ./blueriver_bitmap_streamer)
> ./blueriver_bitmap_streamer: /lib/aarch64-linux-gnu/libc.so.6: version 
> `GLIBC_2.32' not found (required by ./blueriver_bitmap_streamer)
> ./blueriver_bitmap_streamer: /lib/aarch64-linux-gnu/libc.so.6: version 
> `GLIBC_2.33' not found (required by ./blueriver_bitmap_streamer)
> ./blueriver_bitmap_streamer: /lib/aarch64-linux-gnu/libc.so.6: version 
> `GLIBC_2.34' not found (required by ./blueriver_bitmap_streamer)
> root@raspberrypi:/home/bitmap_overlap/linux-aarch64#

Your libc6 and libstdc++6 packages are too old to run this program.
Your choices are:

1) Find another, older, build of this program that's suitable for your
   system.

2) Recompile it yourself, if source code is available.

3) Find a substitute program.

4) Upgrade your operating system to a newer release.

Debian 12 (bookworm) should be new enough:

hobbit:~$ nm -D /lib/x86_64-linux-gnu/libc.so.6 | grep 'A GLIBC_2\.3[0-9]'
 A GLIBC_2.30
 A GLIBC_2.31
 A GLIBC_2.32
 A GLIBC_2.33
 A GLIBC_2.34
 A GLIBC_2.35
 A GLIBC_2.36

hobbit:~$ nm -D /lib/x86_64-linux-gnu/libstdc++.so.6 | grep 'A 
GLIBCXX_3\.4\.[23][0-9]'
 A GLIBCXX_3.4.20
 A GLIBCXX_3.4.21
 A GLIBCXX_3.4.22
 A GLIBCXX_3.4.23
 A GLIBCXX_3.4.24
 A GLIBCXX_3.4.25
 A GLIBCXX_3.4.26
 A GLIBCXX_3.4.27
 A GLIBCXX_3.4.28
 A GLIBCXX_3.4.29
 A GLIBCXX_3.4.30

Re: running Jami in Trixie - possible locale issue

[Greg Wooledge]

On Mon, Feb 26, 2024 at 10:10:45PM -0500, Gremlin wrote:
> On 2/26/24 20:28, Gary Dale wrote:
> > > > > > $locale
> > > > > > locale: Cannot set LC_CTYPE to default locale: No such
> > > > > > file or directory
> > > > > > locale: Cannot set LC_MESSAGES to default locale: No
> > > > > > such file or directory
> > > > > > locale: Cannot set LC_ALL to default locale: No such file or 
> > > > > > directory
> > > > > > LANG=iu_CA.UTF-8
> > > > > > LANGUAGE=en_GB
> > > > > > LC_CTYPE="iu_CA.UTF-8"
> > > > > > LC_NUMERIC=en_CA.UTF-8
> > > > > > LC_TIME=en_CA.UTF-8
> > > > > > LC_COLLATE=en_CA.UTF-8
> > > > > > LC_MONETARY=en_CA.UTF-8
> > > > > > LC_MESSAGES="iu_CA.UTF-8"
> > > > > > LC_PAPER="iu_CA.UTF-8"
> > > > > > LC_NAME="iu_CA.UTF-8"
> > > > > > LC_ADDRESS="iu_CA.UTF-8"
> > > > > > LC_TELEPHONE="iu_CA.UTF-8"
> > > > > > LC_MEASUREMENT=en_CA.UTF-8
> > > > > > LC_IDENTIFICATION="iu_CA.UTF-8"
> > > > > > LC_ALL=

> > $locale -a
> > locale: Cannot set LC_CTYPE to default locale: No such file or directory
> > locale: Cannot set LC_MESSAGES to default locale: No such file or directory
> > C
> > C.utf8
> > en_CA.utf8
> > en_US.utf8
> > fr_CA.utf8
> > POSIX
> > 
> > 
> 
> Find out where LC_CTYPE and LC_MESSAGES is being set, they need changed.

No, you're not reading it correctly.  Look at LANG.  Look at the double
quotes around LC_CTYPE and LC_MESSAGES (among others).  LC_CTYPE and
LC_MESSAGES are *not* set.  They are deduced from LANG.

It's LANG that has the weird setting.  All of the other iu_CA entries
are double-quoted, so they are derived from it.

> If it was me, I would set /etc/default/locale to
> #  File generated by update-locale
> LANG=C.UTF-8
> 
> and remove all references/assignments to any LC_ in all shell
> config files.
> 
> then reboot and do a locale -a

Rebooting doesn't do anything useful here.  Simply logging out and back
in would be sufficient.

But there are two points of view here:

1) Why is Gary using locales that are not generated?

2) Why is Gary using *these specific* locales?

I think you're approaching it from the point of view of "your settings
are wrong, but you don't know where the settings are coming from, so
find out, and fix them".  Which is one valid POV.

Another valid POV is "the settings are set the way Gary wants them, but
the locales aren't generated, so generate them, and then it'll work".

Only Gary can tell us which of these is the right approach.  Maybe he's
a fluent Inuktitut speaker.  All I can say is that it's hard to believe
that someone would *accidentally* have LANG set to iu_CA.UTF-8.  Usually
that's the kind of thing one would remember doing.