Re: Problema chroot sid

[griera]

Hola, Jordi:

On Thu, 7 Mar 2024 20:31:51 +0100
Jordi Miguel  wrote:

> Hola,
> 
> Una altre alternativa quan vols/necessites utilitzar versions més
> modernes d'algun programari es mirar si esta empaquetat amb snap,
> flatpak o AppImage.
> Pel teu cas, el Handbrake el tens disponible com a flatpak [1]

Sí, de fet, fins que no vaig solucionar el chroot, el vaig instal·lar amb 
flatpak. Però com és una cosa que desconec del tot, l'esborrat al poder 
instal·lar sid.

Una pregunta: si tinc instal·lat programes en flatpak i apareixent 
actualitzacions de seguretat, aquestes també s'apliquen al que està instal·lat 
com flatpak? Mai l'he fet servir per por de que les actualitzacions no 
s'apliquin.


> I si no tens instal·lat el suport per flatpak es tan fácil com seguir
> la guia [2], tot el necessari esta disponible en els repos de Debian
> des de la versió 10 (Buster)

Gràcies! M'ho miro.

Salut!

> 
> [1] https://flathub.org/apps/fr.handbrake.ghb
> [2] https://flathub.org/setup/Debian
> 
> 
> Fins aviat,
> --
> Para ser realmente grande, hay que estar con la gente, no por encima de ella.
> 
> El jue, 7 mar 2024 a las 10:56,  escribió:
> >
> > Moltes gràcies per l'interès, Alex!
> >
> > On Wed, 6 Mar 2024 22:53:11 +0100
> > Alex Muntada  wrote:
> >
> > > Hola,
> > >
> > > > 2024-03-04 08:20:28 
> > > > URL:http://deb.debian.org/debian/pool/main/z/zlib/zlib1g_1.3.dfsg-3.1_amd64.deb
> > > >  [87580/87580] -> 
> > > > "/srv/chroot/sid//var/cache/apt/archives/partial/zlib1g_1%3a1.3.dfsg-3.1_amd64.deb"
> > > >  [1]
> > > > tar: ./usr/lib/x86_64-linux-gnu/libuuid.so.1.3.0: Cannot open: File 
> > > > exists
> > > > tar: ./usr/lib/x86_64-linux-gnu/libuuid.so.1: Cannot create symlink to 
> > > > 'libuuid.so.1.3.0': File exists
> > > > tar: Exiting with failure status due to previous errors
> > >
> > > Ho he tornat a provar ara i l'error era diferent: es queixava
> > > d'una incompatibilitat entre libssl3t64 i libssl3. Això m'ha
> > > fet pensar que, essent sid la versió inestable, potser hi ha
> > > alguna transició en marxa i he trobat això:
> > >
> > > https://release.debian.org/transitions/html/auto-openssl.html
> >
> > No en se prou com per avaluar tot això i me perdo.
> >
> >
> > > > Els primers cops no me'n vaig adonar d'aquest error. Total que he 
> > > > enviat un bug:
> > > >
> > > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1065343
> > >
> > > He vist que han resolt una part, però segueix fallant el
> > > debootstrap per altres transicions que hi ha en marxa.
> > > Segurament debootstrap no està pensat per utilitzar-se amb
> > > sid, encara que s'utilitzi el de backports, perquè instal·la els
> > > paquets amb dpkg directament enlloc de fer-ho amb apt.
> > >
> > > He provat el mmdebstrap que suggereixen al bug i a mi també
> > > m'ha funcionat bé (com deia abans, mmdebstrap utilitza apt per
> > > instal·lar els paquets i aleshores resol millor les dependències
> > > que debootstrap).
> >
> > Sí,amb:
> >
> > sudo mmdebstrap sid /srv/chroot/sid
> >
> > no hi ha cap problema. Aquesta comanda, que desconeixia, m'ha salvat.
> >
> >
> > > > Vols dir que no utilitzes el debootstrap de bookworm-backports?
> > > > No ho entenc, perquè si utilitzo el debootstrap de bookworm en
> > > > lloc del de bookworm-backports a mi me surt el mateix error de
> > > > "Cannot open: File exists".
> > >
> > > Perquè el problema està a la resolució de dependències que
> > > comento més amunt en una versió del sistema que és inestable per
> > > les transicions que hi ha constantment:
> > >
> > > https://release.debian.org/transitions/
> >
> > Ja, però en un chroot va molt bé per executar aplicacions que tenen 
> > problemes en la versió estable (en aquest cas, hadbrake, que en el versió 
> > estable, al gravar els subtítols, els grava doble) o que necessites una 
> > versió més actual. Sempre estic a estable i acabo instal·lant una sid en un 
> > chroot. Per mi, molt millor que una màquina virtual.
> >
> > Gràcies per tota aquesta ajuda i salut!
> >
> >
> > >
> > > Salut,
> > > Alex
> > >
> > > --
> > >   ⢀⣴⠾⠻⢶⣦⠀
> > >   ⣾⠁⢠⠒⠀⣿⡁   Alex Muntada 
> > >   ⢿⡄⠘⠷⠚⠋   Debian Developer  log.alexm.org
> > >   ⠈⠳⣄
> > >
> >

Re: Problema chroot sid

[griera]

On Thu, 7 Mar 2024 17:05:26 +0100
Alex Muntada  wrote:

Gràcies, Alex per comentar aquestes reflexions!

> Hola,
> 
> > > https://release.debian.org/transitions/html/auto-openssl.html
> > 
> > No en se prou com per avaluar tot això i me perdo.
> 
> De vegades, jo també :)
> 
> En aquest en cas particular, si ho interpreto bé, la idea és que
> estan transicionant de libssl3 a libssl3t64 (imagino que degut a
> la transició del tipus time_t a 64 bits, que ho esquitxa tot).
> 
> Però la meva idea esmentant les transicions era fer una mica de
> pedagodia sobre com funciona sid i que, en un moment determinat,
> pot haver-hi coses trencades.
> 
> > Ja, però en un chroot va molt bé per executar aplicacions que
> > tenen problemes en la versió estable (en aquest cas, hadbrake,
> > que en el versió estable, al gravar els subtítols, els grava
> > doble) o que necessites una versió més actual. Sempre estic a
> > estable i acabo instal·lant una sid en un chroot. Per mi, molt
> > millor que una màquina virtual.
> 
> Jo tinc el chroot de sid per a fer desenvolupament de paquets
> Debian, però algun cop també em va bé per provar versions més
> noves d'algun paquet. Em sembla una bona solució, només has de
> tenir en compte que, segons el que facis, pots interferir al
> sistema principal (per exemple, aturant algun servei sense
> voler).

Totalment inconscient d'això! Però intento fer coses molt senzilles. Fins ara 
no he tingut cap problema que en fos conscient.


> La dificultat principal que té sid és instal·lar-la per primer
> cop. Quan ja ho tens, actualitzar-la regularment funciona bé.
> Només passa de tant en tant que hi ha coses trencades i que no
> pots actualitzar alguns paquets fins que ho solucionin.
> 
> En aquest sentit, quan m'ha calgut tenir una màquina virtual amb
> unstable per fer desenvolupament, el que faig és una instal·lació
> de testing i després l'actualitzo a unstable. Per exemple: no hi
> ha cap ISO d'instal·lació per a unstable, que jo sàpiga.
> 
> Per tot plegat, aquest fil m'ha semblat molt educatiu. Gràcies!

Sí, molt educatiu.Gràcies i salut!


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

Re: very poor nfs performance

[Mike Kupfer]

Stefan K wrote:

> 'sync'-mountoption is important (more or less), but it should still be
> much faster than 20MB/s

I don't know if "sync" could be entirely responsible for such a
slowdown, but it's likely at least contributing, particularly if the
application is doing small I/Os at the system call level.

You could try removing the "sync" option, just as an experiment, to see
how much it is contributing to the slowdown.

mike

Re: libbusiness-us-usps-webtools-perl and USPS Ground Advantage shipping

[hw]

On Thu, 2024-03-07 at 23:15 -0500, Jeffrey Walton wrote:
> Hi Everyone,
> 
> I need to generate some shipping labels for drop-off at the USPS post
> office using USPS Ground Advantage.
> 
> I have a USB thermal printer for the shipping labels,
> .
> 
> I see Debian carries libbusiness-us-usps-webtools-perl. I visited the
> module's GitHub at
> , but the
> examples are on the lite side. I don't see a workflow similar to
> creating and printing a shipping label.
> 
> My question is, can I use the module to create and print a shipping
> label for a USPS Ground Advantage package?

When you look at the documentation at
https://metacpan.org/pod/Business::US::USPS::WebTools it looks as if
this doesn't do any printing.  The most recent commit seems to be 3
years old and I doubt that this library is still useful since the web
services it uses have probably changed in the meantime.

If you can print on the printer and want to automate printing labels,
you could use LaTeX.  Other options like scribus and libreoffice don't
run headless (unless scribus has changed).  However, I don't know what
these labels look like.

This printer has only 300dpi.  If you print QR-codes on it make sure
you can scan them: they have to be large enough or get you an
unscanable smear.



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

libbusiness-us-usps-webtools-perl and USPS Ground Advantage shipping

[Jeffrey Walton]

Hi Everyone,

I need to generate some shipping labels for drop-off at the USPS post
office using USPS Ground Advantage.

I have a USB thermal printer for the shipping labels,
.

I see Debian carries libbusiness-us-usps-webtools-perl. I visited the
module's GitHub at
, but the
examples are on the lite side. I don't see a workflow similar to
creating and printing a shipping label.

My question is, can I use the module to create and print a shipping
label for a USPS Ground Advantage package?

Thanks in advance.

Re: strange time problem with bullseye/buster

[gene heskett]

On 3/7/24 21:30, David Wright wrote:

On Thu 07 Mar 2024 at 19:17:02 (-0500), gene heskett wrote:

On 3/7/24 12:19, David Wright wrote:

On Thu 07 Mar 2024 at 11:29:47 (-0500), gene heskett wrote:

On 3/7/24 10:59, Greg Wooledge wrote:



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.


and because the printer is arm stuff, its old armbian buster vintage.
mks@mkspi:/etc/init.d$ sudo apt purge systemd-timesyncd
Reading package lists... Done
Building dependency tree
Reading state information... Done
Package 'systemd-timesyncd' is not installed, so not removed
0 upgraded, 0 newly installed, 0 to remove and 2 not upgraded.
mks@mkspi:/etc/init.d$
yet timedatectl is still there and shows:
mks@mkspi:/etc/init.d$ timedatectl
 Local time: Thu 2024-03-07 11:15:53 EST
 Universal time: Thu 2024-03-07 16:15:53 UTC
   RTC time: Thu 2024-03-07 11:04:39
  Time zone: America/New_York (EST, -0500)
System clock synchronized: no
NTP service: inactive
RTC in local TZ: no
mks@mkspi:/etc/init.d$
And the local time shown above is correct to the second.


Debian's buster's systemd (241) has timesyncd built-in, so you may
find that   ls -l /lib/systemd/systemd-timesyncd still finds it.

The output from timedatectl is worrying. I would monitor chrony and
check its logs to see if it it's doing anything. After all, you had
ntpsec running until a "moment" ago, so you'd hardly expect the clock
to be wrong by now.


At the instant I removed ntpsec and minute later whem I re-installed
chrony, the time on that printer was around 20 hours stale. By about a
minute after chrony started, which the install did, time was
synchronized.

And still is. Somehow, it resurrected the customized
/etc/chrony/chrony.conf which pointed it at this machines ntpsec
server. So I didn't have to re-invent that wheel. It just Worked.
Memory in the u-sd card? IDK.

I have NDI how to extract chrony's logs from journalctl.


You could run these commands as an ordinary user instead:

   $ chronyc sources
   $ chronyc sourcestats
   $ chronyc tracking

which will give you an idea of what it is doing.

Cheers,
David.

.

mks@mkspi:/etc/init.d$ chronyc tracking
Reference ID: C0A84703 (coyote.coyote.den)
Stratum : 4
Ref time (UTC)  : Fri Mar 08 03:23:48 2024
System time : 0.06175 seconds slow of NTP time
Last offset : -0.05491 seconds
RMS offset  : 0.07778 seconds
Frequency   : 6.590 ppm slow
Residual freq   : -0.002 ppm
Skew: 0.036 ppm
Root delay  : 0.034696314 seconds
Root dispersion : 0.054448538 seconds
Update interval : 64.5 seconds
Leap status : Normal

Looks good to me. ;o)>

Thanks David. Take care & stay well.

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

Re: strange time problem with bullseye/buster

[David Wright]

On Thu 07 Mar 2024 at 19:17:02 (-0500), gene heskett wrote:
> On 3/7/24 12:19, David Wright wrote:
> > On Thu 07 Mar 2024 at 11:29:47 (-0500), gene heskett wrote:
> > > On 3/7/24 10:59, Greg Wooledge wrote:
> > 
> > > > 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.
> > > > 
> > > and because the printer is arm stuff, its old armbian buster vintage.
> > > mks@mkspi:/etc/init.d$ sudo apt purge systemd-timesyncd
> > > Reading package lists... Done
> > > Building dependency tree
> > > Reading state information... Done
> > > Package 'systemd-timesyncd' is not installed, so not removed
> > > 0 upgraded, 0 newly installed, 0 to remove and 2 not upgraded.
> > > mks@mkspi:/etc/init.d$
> > > yet timedatectl is still there and shows:
> > > mks@mkspi:/etc/init.d$ timedatectl
> > > Local time: Thu 2024-03-07 11:15:53 EST
> > > Universal time: Thu 2024-03-07 16:15:53 UTC
> > >   RTC time: Thu 2024-03-07 11:04:39
> > >  Time zone: America/New_York (EST, -0500)
> > > System clock synchronized: no
> > >NTP service: inactive
> > >RTC in local TZ: no
> > > mks@mkspi:/etc/init.d$
> > > And the local time shown above is correct to the second.
> > 
> > Debian's buster's systemd (241) has timesyncd built-in, so you may
> > find that   ls -l /lib/systemd/systemd-timesyncd still finds it.
> > 
> > The output from timedatectl is worrying. I would monitor chrony and
> > check its logs to see if it it's doing anything. After all, you had
> > ntpsec running until a "moment" ago, so you'd hardly expect the clock
> > to be wrong by now.
> 
> At the instant I removed ntpsec and minute later whem I re-installed
> chrony, the time on that printer was around 20 hours stale. By about a
> minute after chrony started, which the install did, time was
> synchronized.
> 
> And still is. Somehow, it resurrected the customized
> /etc/chrony/chrony.conf which pointed it at this machines ntpsec
> server. So I didn't have to re-invent that wheel. It just Worked.
> Memory in the u-sd card? IDK.
> 
> I have NDI how to extract chrony's logs from journalctl.

You could run these commands as an ordinary user instead:

  $ chronyc sources
  $ chronyc sourcestats
  $ chronyc tracking

which will give you an idea of what it is doing.

Cheers,
David.

Re: Spam from the list?

[Tim Woodall]

On Thu, 7 Mar 2024, Andy Smith wrote:


Hi,

On Thu, Mar 07, 2024 at 09:44:51AM +0100, Hans wrote:
> --- sninp ---
> 
> Authentication-Results: mail35c50.megamailservers.eu; spf=none 
> smtp.mailfrom=lists.debian.org

> Authentication-Results: mail35c50.megamailservers.eu;
> 	dkim=fail reason="signature verification failed" (2048-bit key) 
> header.d=debian.org header.i=@debian.org header.b="pDp/TPD5"

> Return-Path: 
> Received: from bendel.debian.org (bendel.debian.org [82.195.75.100])
> 	by mail35c50.megamailservers.eu (8.14.9/8.13.1) with ESMTP id 
> 425I9ZEK112497

>for ; Tue, 5 Mar 2024 18:09:37 +
> 
> --- snap ---
> 
> White mails get the dkim=pass and spam mails got dkim=fail (as you see above).


A great many legitimate emails will fail DKIM so it is not a great
idea to reject every email that does so. I don't think that you are
going to have a good time using Internet mailing lists while your
mail provider rejects mails with invalid DKIM, so if I were you I'd
work on fixing that rather than trying to get everyone involved to
correctly use DKIM.


And some dkim seems setup with the intention that it should not be used
for mailinglusts:

DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
d=dow.land;
s=20210720;
h=From:In-Reply-To:References:Subject:To:Message-Id:Date:
Content-Type:Content-Transfer-Encoding:Mime-Version:Sender:Reply-To:Cc:
Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender:
Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:
List-Subscribe:List-Post:List-Owner:List-Archive;

This one passed on bendel but not when it got to me. Most on debian-user
seem ok, debian-devel does seem to get more submissions with broken dkim
(based on looking at a random handful on each list)

AFAICT, it's a problem at the originator causing failures, either
something wrong with dkim setup or too strict set of headers.

I shall be checking what this does when it gets back to me. One of the
problems with dkim is that you assume it still works, it's hard to know
what others actually see...

Re: Spam from the list?

[John Crawley]

On 07/03/2024 21:04, Andy Smith wrote:

Hi,

On Thu, Mar 07, 2024 at 09:44:51AM +0100, Hans wrote:

--- sninp ---

Authentication-Results: mail35c50.megamailservers.eu; spf=none
smtp.mailfrom=lists.debian.org
Authentication-Results: mail35c50.megamailservers.eu;
dkim=fail reason="signature verification failed" (2048-bit key)
header.d=debian.org header.i=@debian.org header.b="pDp/TPD5"
Return-Path: 
Received: from bendel.debian.org (bendel.debian.org [82.195.75.100])
by mail35c50.megamailservers.eu (8.14.9/8.13.1) with ESMTP id
425I9ZEK112497
for ; Tue, 5 Mar 2024 18:09:37 +

--- snap ---

White mails get the dkim=pass and spam mails got dkim=fail (as you see above).


A great many legitimate emails will fail DKIM so it is not a great
idea to reject every email that does so. I don't think that you are
going to have a good time using Internet mailing lists while your
mail provider rejects mails with invalid DKIM, so if I were you I'd
work on fixing that rather than trying to get everyone involved to
correctly use DKIM.

In this specific example your problem is that a mail came through
the Debian bug tracking system (which pretends to be the original
sender) and on the way out was DKIm signed by debian.org and then
went through Debian's list servers. Somewhere in there the DKIM
signature was broken.

I don't rate your chances of getting the operators of
bugs.debian.org and lists.debian.org to agree to preserve DKIM since
I know at least some of them are severely opposed to DKIM.

Your mailbox provider really should not be rejecting everything that
has a broken DKIm signature. This email from me will probably have a
broken DKIM signature.

Thanks,
Andy


Andy's mail's DKIM looks OK here:

Authentication-Results: mx.zohomail.com;
dkim=pass;
spf=none (zohomail.com: 82.195.75.100 is neither permitted nor denied 
by domain of lists.debian.org)  
smtp.mailfrom=bounce-debian-user=john=bunsenlabs@lists.debian.org;
dmarc=pass(p=none dis=none)  header.from=strugglers.net
ARC-Seal: i=1; a=rsa-sha256; t=1709813111; cv=none;
d=zohomail.com; s=zohoarc;

b=E/0YtYVq6D01XC5ug3vazK169M6jDxoXOO6K7rs6qdKhNHP1XDV7QSLAvwJetsjzooDe39MNSl/160MWgl3URqQ1YhPYZ9aBFQ3DsmN74mTKPiQYOxqx0XzNy1Nemo4oRetVQDrwEGeegQWUBbrxtbD18x8R7Dd9Ps19NxKRMP8=
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; 
s=zohoarc;
t=1709813111; 
h=Content-Type:Date:Date:From:From:In-Reply-To:List-Subscribe:List-Post:List-Id:List-Archive:List-Help:List-Unsubscribe:MIME-Version:Message-ID:Resent-Sender:Resent-Date:References:Resent-Message-ID:Resent-From:Subject:Subject:To:To:Message-Id:Reply-To:Cc;
bh=ohelUf+wTnNtAeaNpYE6UONuc2euPhvqBvxLaU7Fz7c=;

b=MUW94hTSknXpUch7F94usVvulKMrwldlWtoyP582oO6+EMhKaeisaBraF7KE46pdbHyE+AAzf/dn0xPDxNnN+M+RXSbXsQvu7qEIe/+q6fCdppDhql+IMx+U9H+Q61olqpD+JMh9IxFgAUSKme0bLD8NhFKOskvLdtzqq3XeIpg=
ARC-Authentication-Results: i=1; mx.zohomail.com;
dkim=pass;
spf=none (zohomail.com: 82.195.75.100 is neither permitted nor denied 
by domain of lists.debian.org)  
smtp.mailfrom=bounce-debian-user=john=bunsenlabs@lists.debian.org;
dmarc=pass header.from= (p=none dis=none)

--snip--

DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
d=strugglers.net; s=alpha; 
h=In-Reply-To:Content-Type:MIME-Version:References

:Message-ID:Subject:To:From:Date:Content-Transfer-Encoding:Sender:Reply-To:Cc
:Content-ID:Content-Description:Resent-To;
bh=ohelUf+wTnNtAeaNpYE6UONuc2euPhvqBvxLaU7Fz7c=; 
b=c5YTQp9JWbbPNuLxDYO19XXqgy

KmEiV4tSD2LlNXy4C9/5PPfZ5JGT6U70UQpwIXgC1alHcUyD+LY6JDPEbO33KuWsWr4gvrJCwrq0u

HMUc+sKwQgknFeLxa5Jk3a3VFLURsYYec+6Lc9C4WsQB9I+xuv8CmO22xpRRNqB3SWdR7gtHy+Ab8

1UGvqoeEsCAtc5y2dt3uiX6Uy5qYDRbgbSVBhfq4TwjxmyTqmnkT1oG62tW2LavipJDvfR/40weCR

B/S7To5h6Lgc/1oLArFNtrtPlfyyRg38maGSj5Jgt9X5Vwdfg187lIla/I4OBjib2pDV5d38QzL7v
4Vz0PYFg==;

--
John

Re: Commandline client to lookup MAC vendor

[Jeffrey Walton]

On Thu, Mar 7, 2024 at 4:06 AM Ralph Aichinger  wrote:
>
> Several packages in Debian can somehow (either by embedding it or
> querying it from some common database) display the MAC Vendor
> information of network adapters (derived from hardware addresses).
>
> One example is nmap, that displays the device vendor when scanning.
>
> Is there some commandline tool doing this directly in Debian? I know
> that there are websites that offer this as a service, but sometimes a
> CLI is more convenient.
>
> Alternatively, and if this information is stored in some shared
> databases, can this be queried e.g. from a Pyhton script? If so, how?

Here's a Python project that does what you want:
. The update function
uses  as Lee suggested.

Jeff

Re: strange time problem with bullseye

[gene heskett]

On 3/7/24 14:16, Roy J. Tellason, Sr. wrote:

On Wednesday 06 March 2024 12:42:12 pm Greg Wooledge wrote:

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.


True, but needs a sudo in front if it in my case on that armbian buster 
machine.
  
That seemed to do what I needed.


I don't ordinarily shut this machine down for the most part.  Every once in a while all 
of my swap partition gets filled up,  and then there's this continuous hard drive 
activity that I'm assuming is what they mean by "thrashing". The only option at 
that point is to get its attention with the power switch.  And then I need to go through 
a whole routing with bringing up what I had going,  including re-starting virtualbox and 
the stuff that runs in it,  etc.  If I'm lucky then I can get back the windows I had 
going before,  sometimes I'm not so lucky.  A system monitor I run on desktop 4 always 
comes up,  but on the wrong desktop and I have to move it.

The "eat all available memory" culprit seems to be firefox.  I just need to 
look at that system monitor every once in a while and when things start getting excessive 
shut firefox down and restart it.  Then I don't have the problem...

I'm not sure if I have ntp or something else running here.  (Looking...)  I 
don't see it in my process list.




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

Re: strange time problem with bullseye/buster

[gene heskett]

On 3/7/24 12:19, David Wright wrote:

On Thu 07 Mar 2024 at 11:29:47 (-0500), gene heskett wrote:

On 3/7/24 10:59, Greg Wooledge wrote:



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.


and because the printer is arm stuff, its old armbian buster vintage.
mks@mkspi:/etc/init.d$ sudo apt purge systemd-timesyncd
Reading package lists... Done
Building dependency tree
Reading state information... Done
Package 'systemd-timesyncd' is not installed, so not removed
0 upgraded, 0 newly installed, 0 to remove and 2 not upgraded.
mks@mkspi:/etc/init.d$
yet timedatectl is still there and shows:
mks@mkspi:/etc/init.d$ timedatectl
Local time: Thu 2024-03-07 11:15:53 EST
Universal time: Thu 2024-03-07 16:15:53 UTC
  RTC time: Thu 2024-03-07 11:04:39
 Time zone: America/New_York (EST, -0500)
System clock synchronized: no
   NTP service: inactive
   RTC in local TZ: no
mks@mkspi:/etc/init.d$
And the local time shown above is correct to the second.


Debian's buster's systemd (241) has timesyncd built-in, so you may
find that   ls -l /lib/systemd/systemd-timesyncd still finds it.

The output from timedatectl is worrying. I would monitor chrony and
check its logs to see if it it's doing anything. After all, you had
ntpsec running until a "moment" ago, so you'd hardly expect the clock
to be wrong by now.


At the instant I removed ntpsec and minute later whem I re-installed 
chrony, the time on that printer was around 20 hours stale. By about a 
minute after chrony started, which the install did, time was synchronized.


And still is. Somehow, it resurrected the customized
/etc/chrony/chrony.conf which pointed it at this machines ntpsec server. 
So I didn't have to re-invent that wheel. It just Worked. Memory in the 
u-sd card? IDK.


I have NDI how to extract chrony's logs from journalctl.


I tried installing chrony in 2017 (jessie), and it appeared unable
to slew the clock five seconds in two days of interrupted running.

Cheers,
David.


Thank you David, take care & stay well.

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

Re: Cheese ne voit ma caméra qu'en mode root, et drôles de permissions

[François TOURDE]

Le 19789ième jour après Epoch,
Guilhem Bonnefille écrivait:

>> Je ne sais pas ce que signifie le "+" après la liste des droits de ces 
>> fichiers
>
> Ce sont des attributs étendus, consultables avec la commande getfacl.

Cool, merci ! Je connaissait lsattr, mais pas getfacl !

Re: Cheese ne voit ma caméra qu'en mode root, et drôles de permissions

[Guilhem Bonnefille]

> Je ne sais pas ce que signifie le "+" après la liste des droits de ces 
> fichiers

Ce sont des attributs étendus, consultables avec la commande getfacl.

Le jeu. 7 mars 2024 à 22:21, François TOURDE
 a écrit :
>
> Salut la liste.
>
> Depuis une réinstallation de ma machine (bookworm, kernel
> 6.1.0-18-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.1.76-1) cheese n'affiche
> ma caméra que quand je le lance avec le user root.
>
> Avec mon user, la trace console de cheese est:
>
> francois@mersenne:~$ cheese
>
> (cheese:314269): cheese-WARNING **: 21:51:39.774: Internal data stream 
> error.: ../libs/gst/base/gstbasesrc.c(3132): gst_base_src_loop (): 
> /GstCameraBin:camerabin/GstWrapperCameraBinSrc:camera_source/GstBin:bin28/GstPipeWireSrc:pipewiresrc1:
> streaming stopped, reason not-negotiated (-4)
>
> Et le message à la place de la vidéo est:
>
> Une erreur est intervenue pendant la lecture de la vidéo de la webcam
>
> Les permissions dans /dev sont les suivantes:
>
>   crw-rw+  1 root video   241,   0 15 févr. 11:19 /dev/media0
>   crw-rw+  1 root video81,   0 15 févr. 11:19 /dev/video0
>   crw-rw+  1 root video81,   1 15 févr. 11:19 /dev/video1
>
> et mon user est bien dans le groupe video.
>
> Je ne sais pas ce que signifie le "+" après la liste des droits de ces
> fichiers, et je n'ai aucune idée de pourquoi seul root est autorisé à
> accéder à la webcam.
>
> Merci d'avance pour vos indices :)
>


-- 
Guilhem BONNEFILLE
-=- mailto:guilhem.bonnefi...@gmail.com
-=- http://nathguil.free.fr/

Re: Commandline client to lookup MAC vendor

[Thomas Pircher]

Lee wrote:

I haven't tried either package - I just use the file from IEEE


Sure, that's directly from the source. One has to find a compromise
between always using the latest version and using a limited common
resources (like ieee's bandwidth in this case) in a responsible way.

Thomas

Cheese ne voit ma caméra qu'en mode root, et drôles de permissions

[François TOURDE]

Salut la liste.

Depuis une réinstallation de ma machine (bookworm, kernel
6.1.0-18-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.1.76-1) cheese n'affiche
ma caméra que quand je le lance avec le user root.

Avec mon user, la trace console de cheese est:

francois@mersenne:~$ cheese

(cheese:314269): cheese-WARNING **: 21:51:39.774: Internal data stream error.: 
../libs/gst/base/gstbasesrc.c(3132): gst_base_src_loop (): 
/GstCameraBin:camerabin/GstWrapperCameraBinSrc:camera_source/GstBin:bin28/GstPipeWireSrc:pipewiresrc1:
streaming stopped, reason not-negotiated (-4)

Et le message à la place de la vidéo est:

Une erreur est intervenue pendant la lecture de la vidéo de la webcam

Les permissions dans /dev sont les suivantes:

  crw-rw+  1 root video   241,   0 15 févr. 11:19 /dev/media0
  crw-rw+  1 root video81,   0 15 févr. 11:19 /dev/video0
  crw-rw+  1 root video81,   1 15 févr. 11:19 /dev/video1

et mon user est bien dans le groupe video.

Je ne sais pas ce que signifie le "+" après la liste des droits de ces
fichiers, et je n'ai aucune idée de pourquoi seul root est autorisé à
accéder à la webcam.

Merci d'avance pour vos indices :)

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: strange time problem with bullseye

[Dan Ritter]

Roy J. Tellason, Sr. wrote: 
> I don't ordinarily shut this machine down for the most part.  Every once in a 
> while all of my swap partition gets filled up,  and then there's this 
> continuous hard drive activity that I'm assuming is what they mean by 
> "thrashing". The only option at that point is to get its attention with the 
> power switch.  And then I need to go through a whole routing with bringing up 
> what I had going,  including re-starting virtualbox and the stuff that runs 
> in it,  etc.  If I'm lucky then I can get back the windows I had going 
> before,  sometimes I'm not so lucky.  A system monitor I run on desktop 4 
> always comes up,  but on the wrong desktop and I have to move it.
> 
> The "eat all available memory" culprit seems to be firefox.  I just need to 
> look at that system monitor every once in a while and when things start 
> getting excessive shut firefox down and restart it.  Then I don't have the 
> problem...

There's a kernel feature called the OOM-killer (out of memory)
which is supposed to detect when you are running out of memory
and select a process to kill.

Did you turn it off? It would be a setting in /etc/sysctl.conf
or /etc/sysctl.d/*

If not, perhaps you have an excessive amount of slow swap for it to be happy?

 
> I'm not sure if I have ntp or something else running here.  (Looking...)  I 
> don't see it in my process list.

Other likely candidates are systemd-timesync and chrony.

-dsr-

Re: Problema chroot sid

[Jordi Miguel]

Hola,

Una altre alternativa quan vols/necessites utilitzar versions més
modernes d'algun programari es mirar si esta empaquetat amb snap,
flatpak o AppImage.
Pel teu cas, el Handbrake el tens disponible com a flatpak [1]

I si no tens instal·lat el suport per flatpak es tan fácil com seguir
la guia [2], tot el necessari esta disponible en els repos de Debian
des de la versió 10 (Buster)

[1] https://flathub.org/apps/fr.handbrake.ghb
[2] https://flathub.org/setup/Debian


Fins aviat,
--
Para ser realmente grande, hay que estar con la gente, no por encima de ella.

El jue, 7 mar 2024 a las 10:56,  escribió:
>
> Moltes gràcies per l'interès, Alex!
>
> On Wed, 6 Mar 2024 22:53:11 +0100
> Alex Muntada  wrote:
>
> > Hola,
> >
> > > 2024-03-04 08:20:28 
> > > URL:http://deb.debian.org/debian/pool/main/z/zlib/zlib1g_1.3.dfsg-3.1_amd64.deb
> > >  [87580/87580] -> 
> > > "/srv/chroot/sid//var/cache/apt/archives/partial/zlib1g_1%3a1.3.dfsg-3.1_amd64.deb"
> > >  [1]
> > > tar: ./usr/lib/x86_64-linux-gnu/libuuid.so.1.3.0: Cannot open: File exists
> > > tar: ./usr/lib/x86_64-linux-gnu/libuuid.so.1: Cannot create symlink to 
> > > 'libuuid.so.1.3.0': File exists
> > > tar: Exiting with failure status due to previous errors
> >
> > Ho he tornat a provar ara i l'error era diferent: es queixava
> > d'una incompatibilitat entre libssl3t64 i libssl3. Això m'ha
> > fet pensar que, essent sid la versió inestable, potser hi ha
> > alguna transició en marxa i he trobat això:
> >
> > https://release.debian.org/transitions/html/auto-openssl.html
>
> No en se prou com per avaluar tot això i me perdo.
>
>
> > > Els primers cops no me'n vaig adonar d'aquest error. Total que he enviat 
> > > un bug:
> > >
> > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1065343
> >
> > He vist que han resolt una part, però segueix fallant el
> > debootstrap per altres transicions que hi ha en marxa.
> > Segurament debootstrap no està pensat per utilitzar-se amb
> > sid, encara que s'utilitzi el de backports, perquè instal·la els
> > paquets amb dpkg directament enlloc de fer-ho amb apt.
> >
> > He provat el mmdebstrap que suggereixen al bug i a mi també
> > m'ha funcionat bé (com deia abans, mmdebstrap utilitza apt per
> > instal·lar els paquets i aleshores resol millor les dependències
> > que debootstrap).
>
> Sí,amb:
>
> sudo mmdebstrap sid /srv/chroot/sid
>
> no hi ha cap problema. Aquesta comanda, que desconeixia, m'ha salvat.
>
>
> > > Vols dir que no utilitzes el debootstrap de bookworm-backports?
> > > No ho entenc, perquè si utilitzo el debootstrap de bookworm en
> > > lloc del de bookworm-backports a mi me surt el mateix error de
> > > "Cannot open: File exists".
> >
> > Perquè el problema està a la resolució de dependències que
> > comento més amunt en una versió del sistema que és inestable per
> > les transicions que hi ha constantment:
> >
> > https://release.debian.org/transitions/
>
> Ja, però en un chroot va molt bé per executar aplicacions que tenen problemes 
> en la versió estable (en aquest cas, hadbrake, que en el versió estable, al 
> gravar els subtítols, els grava doble) o que necessites una versió més 
> actual. Sempre estic a estable i acabo instal·lant una sid en un chroot. Per 
> mi, molt millor que una màquina virtual.
>
> Gràcies per tota aquesta ajuda i salut!
>
>
> >
> > Salut,
> > Alex
> >
> > --
> >   ⢀⣴⠾⠻⢶⣦⠀
> >   ⣾⠁⢠⠒⠀⣿⡁   Alex Muntada 
> >   ⢿⡄⠘⠷⠚⠋   Debian Developer  log.alexm.org
> >   ⠈⠳⣄
> >
>

Re: strange time problem with bullseye

[Roy J. Tellason, Sr.]

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.

-- 
Member of the toughest, meanest, deadliest, most unrelenting -- and
ablest -- form of life in this section of space,  a critter that can
be killed but can't be tamed.  --Robert A. Heinlein, "The Puppet Masters"
-
Information is more dangerous than cannon to a society ruled by lies. --James 
M Dakin

Re: strange time problem with bullseye

[Roy J. Tellason, Sr.]

On Wednesday 06 March 2024 12:42:12 pm Greg Wooledge wrote:
> > 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.
 
That seemed to do what I needed.

I don't ordinarily shut this machine down for the most part.  Every once in a 
while all of my swap partition gets filled up,  and then there's this 
continuous hard drive activity that I'm assuming is what they mean by 
"thrashing". The only option at that point is to get its attention with the 
power switch.  And then I need to go through a whole routing with bringing up 
what I had going,  including re-starting virtualbox and the stuff that runs in 
it,  etc.  If I'm lucky then I can get back the windows I had going before,  
sometimes I'm not so lucky.  A system monitor I run on desktop 4 always comes 
up,  but on the wrong desktop and I have to move it.

The "eat all available memory" culprit seems to be firefox.  I just need to 
look at that system monitor every once in a while and when things start getting 
excessive shut firefox down and restart it.  Then I don't have the problem...

I'm not sure if I have ntp or something else running here.  (Looking...)  I 
don't see it in my process list.


-- 
Member of the toughest, meanest, deadliest, most unrelenting -- and
ablest -- form of life in this section of space,  a critter that can
be killed but can't be tamed.  --Robert A. Heinlein, "The Puppet Masters"
-
Information is more dangerous than cannon to a society ruled by lies. --James 
M Dakin

Re: Hyphen-minus passwd

[Nicolas George]

Greg Wooledge (12024-03-07):
> Looks like you want the -- to separate options from non-option arguments,

Of course.

> 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.

Yes, that is super weird, possibly a mistake. All the more reason to
have the original poster clarify their needs.

Regards,

-- 
  Nicolas George

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: Hyphen-minus passwd

[Nicolas George]

Lee (12024-03-07):
> You're going to rag on him for not copy-pasting EXACTLY when you could
> have just told him the standard way to get a leading hyphen accepted
> on the command line is to backslash escape it!??

Uh, yes, of course. And that would be best even if your answer was not
wrong.

-- 
  Nicolas George

Re: Hyphen-minus passwd

[Nicolas George]

Lee (12024-03-07):
> $ openssl passwd -6 -salt username \\-password
> $6$username$7 ..etc..

Wrong answer: this gives the encrypted string for “\-password”, not for
“-password”.

~ $ openssl passwd -6 -salt username \\-password
$6$username$7Vzj6uFI0bs770qb.tIdqyMDbBWCoF93TKbZ7GSmU0ktiCcMu5rxgjpumDUram2ulYhVlWycvUMf1jGKbu8sC1
~ $ perl -e 'print crypt("-password", "\$6\$username\$"), "\n"'
$6$username$FCvGwi21H/uVp89BtnZHWQsL.vZKajZ3lRbfB7Jnjr2C.5qBgx7TB3Ul3PbcyCIArts/C2lfQgYOLp418oH7C0
~ $ perl -e 'print crypt("\\-password", "\$6\$username\$"), "\n"'
$6$username$7Vzj6uFI0bs770qb.tIdqyMDbBWCoF93TKbZ7GSmU0ktiCcMu5rxgjpumDUram2ulYhVlWycvUMf1jGKbu8sC1

-- 
  Nicolas George

Re: Hyphen-minus passwd

[Lee]

On Thu, Mar 7, 2024 at 12:50 PM Nicolas George wrote:
>
> Computer Planet (12024-03-07):
> > How can I create this password with a hyphen in front?
> >
> > # openssl passwd -6 -salt username -password
> >
> > This is the response message when I try:
> > passwd: Unknown option: -passwd
>
> Hi. No it is not. Start by copy-pasting EXACTLY what is in your
> terminal.

You're going to rag on him for not copy-pasting EXACTLY when you could
have just told him the standard way to get a leading hyphen accepted
on the command line is to backslash escape it!??

rude

Re: Hyphen-minus passwd

[Lee]

On Thu, Mar 7, 2024 at 12:44 PM Computer Planet  wrote:
>
> Hi guys!
> Please, Can someone help me?
>
> How can I create this password with a hyphen in front?
>
> # openssl passwd -6 -salt username -password
>
> This is the response message when I try:
> passwd: Unknown option: -passwd
>
> Thanks for reply!

$ openssl passwd -6 -salt username \\-password
$6$username$7 ..etc..

Re: Hyphen-minus passwd

[Nicolas George]

Computer Planet (12024-03-07):
> How can I create this password with a hyphen in front?
> 
> # openssl passwd -6 -salt username -password
> 
> This is the response message when I try:
> passwd: Unknown option: -passwd

Hi. No it is not. Start by copy-pasting EXACTLY what is in your
terminal.

Also, do not be root when you do not need to.

Regards,

-- 
  Nicolas George

Re: Commandline client to lookup MAC vendor

[Lee]

On Thu, Mar 7, 2024 at 12:22 PM Thomas Pircher wrote:
>
> On 2024-03-07 10:11, Ralph Aichinger wrote:
> > Any idea if one or the other is preferable or newer?
>
> I think there is not much difference between the two files, the
> ieee-data packages the data directly from the IEEE, with nmap you have
> one intermediary project that needs to download and release the file
> before Debian can pick it up.
>
> Then on the other hand, the ieee-data package is one minor version
> behind on the data, while the nmap file was modified ~6 months ago in
> Debian's VCS.
>
> The only difference I can see is that with the ieee-data package you get
> some visibility which upstream version was used, while it would take
> more effort to trace that back in the nmap case.

I haven't tried either package - I just use the file from IEEE
  https://standards-oui.ieee.org/oui/oui.txt

Hyphen-minus passwd

[Computer Planet]

Hi guys!
Please, Can someone help me?

How can I create this password with a hyphen in front?

# openssl passwd -6 -salt username -password

This is the response message when I try:
passwd: Unknown option: -passwd

Thanks for reply!

Re: strange time problem with bullseye/buster

[David Wright]

On Thu 07 Mar 2024 at 11:29:47 (-0500), gene heskett wrote:
> On 3/7/24 10:59, Greg Wooledge wrote:

> > 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.
> > 
> and because the printer is arm stuff, its old armbian buster vintage.
> mks@mkspi:/etc/init.d$ sudo apt purge systemd-timesyncd
> Reading package lists... Done
> Building dependency tree
> Reading state information... Done
> Package 'systemd-timesyncd' is not installed, so not removed
> 0 upgraded, 0 newly installed, 0 to remove and 2 not upgraded.
> mks@mkspi:/etc/init.d$
> yet timedatectl is still there and shows:
> mks@mkspi:/etc/init.d$ timedatectl
>Local time: Thu 2024-03-07 11:15:53 EST
>Universal time: Thu 2024-03-07 16:15:53 UTC
>  RTC time: Thu 2024-03-07 11:04:39
> Time zone: America/New_York (EST, -0500)
> System clock synchronized: no
>   NTP service: inactive
>   RTC in local TZ: no
> mks@mkspi:/etc/init.d$
> And the local time shown above is correct to the second.

Debian's buster's systemd (241) has timesyncd built-in, so you may
find that   ls -l /lib/systemd/systemd-timesyncd still finds it.

The output from timedatectl is worrying. I would monitor chrony and
check its logs to see if it it's doing anything. After all, you had
ntpsec running until a "moment" ago, so you'd hardly expect the clock
to be wrong by now.

I tried installing chrony in 2017 (jessie), and it appeared unable
to slew the clock five seconds in two days of interrupted running.

Cheers,
David.

Re: Installer le noyau 6.6 sur Bookworm

[Michel Verdier]

Le 7 mars 2024 Olivier a écrit :

> J'ai une machine UN305 (processeur Intel Alder lake) sur laquelle j'ai
> installé Bookworm puis le noyau 6.5.
> J'ai besoin d'y installer le noyau 6.6 (pour corriger un problème graphique).

En backport tu as la 6.6.13 disponible. Bizarrement il n'y a que la
unsigned ou alors j'ai mal regardé :
linux-image-6.6.13+bpo-amd64-unsigned
Les sources sont aussi dispo si tu compile ton kernel.
Et les headers si tu as des drivers à compiler :
linux-headers-6.6.13+bpo-amd64

Re: strange time problem with bullseye

[gene heskett]

On 3/7/24 11:18, Jeffrey Walton wrote:

On Thu, Mar 7, 2024 at 8:44 AM  wrote:


On Thu, Mar 07, 2024 at 08:31:16AM -0500, gene heskett wrote:

[...]
Now, how do I assure timedatectl stays stopped on a reboot? [...]

I'll have to leave this to others more fluent in systemd-ish.


Mask the systemd-timesyncd service. Masking is the service a permanent effect.


it appears its not installed. It can't be found to purge it. That would 
explain why it didn't work.


If you just stop or disable the service, then the service will either
be started on the next reboot, or it can be manually started. Since
you want to permanently disable the service, you have to mask it.

Jeff
.

Thanks Jeff.
Take care & stay well.

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

Re: strange time problem with bullseye

[gene heskett]

On 3/7/24 10:59, Greg Wooledge wrote:

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.

.

and because the printer is arm stuff, its old armbian buster vintage.
mks@mkspi:/etc/init.d$ sudo apt purge systemd-timesyncd
Reading package lists... Done
Building dependency tree
Reading state information... Done
Package 'systemd-timesyncd' is not installed, so not removed
0 upgraded, 0 newly installed, 0 to remove and 2 not upgraded.
mks@mkspi:/etc/init.d$
yet timedatectl is still there and shows:
mks@mkspi:/etc/init.d$ timedatectl
   Local time: Thu 2024-03-07 11:15:53 EST
   Universal time: Thu 2024-03-07 16:15:53 UTC
 RTC time: Thu 2024-03-07 11:04:39
Time zone: America/New_York (EST, -0500)
System clock synchronized: no
  NTP service: inactive
  RTC in local TZ: no
mks@mkspi:/etc/init.d$
And the local time shown above is correct to the second.

Thanks Greg, take care & stay well.

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

Re: strange time problem with bullseye

[Jeffrey Walton]

On Thu, Mar 7, 2024 at 8:44 AM  wrote:
>
> On Thu, Mar 07, 2024 at 08:31:16AM -0500, gene heskett wrote:
>
> [...]
> Now, how do I assure timedatectl stays stopped on a reboot? [...]
>
> I'll have to leave this to others more fluent in systemd-ish.

Mask the systemd-timesyncd service. Masking is the service a permanent effect.

If you just stop or disable the service, then the service will either
be started on the next reboot, or it can be manually started. Since
you want to permanently disable the service, you have to mask it.

Jeff

Re: Problema chroot sid

[Alex Muntada]

Hola,

> > https://release.debian.org/transitions/html/auto-openssl.html
> 
> No en se prou com per avaluar tot això i me perdo.

De vegades, jo també :)

En aquest en cas particular, si ho interpreto bé, la idea és que
estan transicionant de libssl3 a libssl3t64 (imagino que degut a
la transició del tipus time_t a 64 bits, que ho esquitxa tot).

Però la meva idea esmentant les transicions era fer una mica de
pedagodia sobre com funciona sid i que, en un moment determinat,
pot haver-hi coses trencades.

> Ja, però en un chroot va molt bé per executar aplicacions que
> tenen problemes en la versió estable (en aquest cas, hadbrake,
> que en el versió estable, al gravar els subtítols, els grava
> doble) o que necessites una versió més actual. Sempre estic a
> estable i acabo instal·lant una sid en un chroot. Per mi, molt
> millor que una màquina virtual.

Jo tinc el chroot de sid per a fer desenvolupament de paquets
Debian, però algun cop també em va bé per provar versions més
noves d'algun paquet. Em sembla una bona solució, només has de
tenir en compte que, segons el que facis, pots interferir al
sistema principal (per exemple, aturant algun servei sense
voler).

La dificultat principal que té sid és instal·lar-la per primer
cop. Quan ja ho tens, actualitzar-la regularment funciona bé.
Només passa de tant en tant que hi ha coses trencades i que no
pots actualitzar alguns paquets fins que ho solucionin.

En aquest sentit, quan m'ha calgut tenir una màquina virtual amb
unstable per fer desenvolupament, el que faig és una instal·lació
de testing i després l'actualitzo a unstable. Per exemple: no hi
ha cap ISO d'instal·lació per a unstable, que jo sàpiga.

Per tot plegat, aquest fil m'ha semblat molt educatiu. Gràcies!

Salut,
Alex

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



signature.asc
Description: PGP signature

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: Passer en 1920x1080 une machine démarrant avec i915.modeset=0 ?

[Olivier]

Après avoir trouvé le rapport [1], j'ai essayé une version Debian Live
de Trixie qui s'appuie sur le noyau 6.6.15.
Avec celle-ci, l'affichage a enfin une résolution appropriée !

Au passage, je note que le module i915 semble cette fois utilisé
(lsmod|grep i915 montre que valeur de 9 au lieu de 0, dans la colonne
"Used by").
J'ignore si la différence de résultat découle :
- soit d'une modification dans le module i915 qui gère les éléments
graphiques Intel
- soit d'une modification dans la lecture des caractéristiques du
moniteur (EDID, ...).

Dès que possible, je compléterai le présent fil de discussion avec de
nouveaux éléments.

[1] https://forum.manjaro.org/t/intel-i915-boot-into-blackscreen-i3-n305/150155

Le jeu. 29 févr. 2024 à 18:48, Jean-Claude Marquès
 a écrit :
>
> Le 29/02/2024 à 10:52, Olivier a écrit :
> Bonjour la liste,
>
> L'option --newmode de xrandr -s avec la modeline  donnée par 
> https://iiyama.com/f/80a1ce9dad07003b56645244ff0addb3_t2452mts-5-usermanual-f.pdf
>  page 26 pourrait peut-être aider (après, il faut sauvegarder cette 
> information pour la retrouver au prochain démarrage...
>
> Mes 0.002€
>
> JCM
>
> Merci à tous pour vos réponses.
>
> À ce stade, j'ai deux pistes à explorer (sans aucun ordre de
> préférence ou de priorité):
> 1- le pilote video  n'est pas correctement installé
> 2- le système n'arrive pas à obtenir les données correctes du moniteur
>
> Pour la piste 1:
>
> Est-il opportun d'observer le module i915 ? Si oui, j'ai:
> # lsmod|grep i915
> i9153936256  0
> drm_buddy 20480  1 i915
> i2c_algo_bit12288  1 i915
> drm_display_helper  233472  1 i915
> cec  69632  2 drm_display_helper,i915
> ttm  106496 1 i915
> drm_kms_helper 2703362 drm_display_helper,i915
> drm 765952 5
> drm_kms_helper,drm_display_helper,drm_buddy,i915,ttm
> video   73728  1 i915
>
> Comment interpréter le 0 après la taille du module ? Sur un autre NUC
> Intel, j'ai une valeur 1.
> Puisqu'ici la machine a un processeur Alder Lake N305, elle intègre un
> circuit graphique UHD.
>
> lspci -vnn | grep -A12 '\''[030[02]\]' | grep -Ei "vga|3d|display|kernel"
> 00:02.0 VGA compatible controller [0300]: Intel Corporation Alder
> Lake-N [UHD Graphics] [8086:46d0] (prog-if 00 [VGA controller])
>
> lshw -c video
>   *-display NON-RÉCLAMÉ
>description: VGA compatible controller
>produit: Alder Lake-N [UHD Graphics]
>fabriquant: Intel Corporation
>identifiant matériel: 2
>information bus: pci@:00:02.0
>version: 00
>bits: 64 bits
>horloge: 33MHz
>fonctionnalités: pciexpress msi pm vga_controller bus_master cap_list
>configuration: latency=0
>ressources: mémoireE/S:600-5ff mémoireE/S:400-3ff
> mémoire:60-6000ff mémoire:40-400fff
> portE/S:5000(taille=64) mémoire:c-d
> mémoire:401000-4016ff mémoire:402000-40
>   *-graphics
>produit: EFI VGA
>identifiant matériel: 1
>nom logique: /dev/fb0
>fonctionnalités: fb
>configuration: depth=32 resolution=800,600
>
> Une option du type "i915.force_probe=4c8a" pourrait-elle fonctionner ?
>
>
>
>
> Pour la piste 2,
>
> Avec deux moniteur IIyama différents, connectés à tour de rôle par HDMI, j'ai:
>
> get-edid
> This is read-edid version 3.0.2. Prepare for some fun.
> Attempting to use i2c interface
> Looks like no busses have an EDID. Sorry!
> Attempting to use the classical VBE interface
>
> Performing real mode VBE call
> Interrupt 0x10 ax=0x4f00 bx=0x0 cx=0x0
> Function unsupported
> Call failed
>
> VBE version 0
> VBE string at 0x0 "O�"
>
> VBE/DDC service about to be called
> Report DDC capabilities
>
> Performing real mode VBE call
> Interrupt 0x10 ax=0x4f15 bx=0x0 cx=0x0
> Function unsupported
> Call failed
>
> Reading next EDID block
>
> VBE/DDC service about to be called
> Read EDID
>
> Performing real mode VBE call
> Interrupt 0x10 ax=0x4f15 bx=0x1 cx=0x0
> Function unsupported
> Call failed
>
> The EDID data should not be trusted as the VBE call failed
> Error: output block unchanged
> I'm sorry nothing was successful. Maybe try some other arguments
> if you played with them, or send an email to Matthew Kern
> .
>
> Qu'en conclure ?
>
> Le jeu. 29 févr. 2024 à 00:07, ajh-valmer  a écrit :
>
> On Wednesday 28 February 2024 21:29:38 Pierre ESTREm wrote:
>
> Faut écrire :
> $ xrandr -s 1920x1080 # Notez le 'x' et pas le '*' :
>
> Pour moi, c'est le pilote vidéo qui n'est plus correctement installé.
> Résolvons le problèmes dans le bon ordre.
>
>
>

Re: Commandline client to lookup MAC vendor

[Thomas Pircher]

On 2024-03-07 10:11, Ralph Aichinger wrote:

Any idea if one or the other is preferable or newer?


I think there is not much difference between the two files, the 
ieee-data packages the data directly from the IEEE, with nmap you have 
one intermediary project that needs to download and release the file 
before Debian can pick it up.


Then on the other hand, the ieee-data package is one minor version 
behind on the data, while the nmap file was modified ~6 months ago in 
Debian's VCS.


The only difference I can see is that with the ieee-data package you get 
some visibility which upstream version was used, while it would take 
more effort to trace that back in the nmap case.


Thomas

Installer le noyau 6.6 sur Bookworm

[Olivier]

Bonjour,

J'ai une machine UN305 (processeur Intel Alder lake) sur laquelle j'ai
installé Bookworm puis le noyau 6.5.
J'ai besoin d'y installer le noyau 6.6 (pour corriger un problème graphique).

Je destine cette machine pour mon usage quotidien (bureautique,
administration système).
C'est pourquoi la stabilité est un critère très important pour moi et
je suis près à attendre quelques semaines, si nécessaire pour
bénéficier d'une stabilité accrue.

Quelle est la méthode recommandée ?

Slts

Re: strange time problem with bullseye

[Teemu Likonen]

* 2024-03-07 08:31:16-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? systemd's
> docs are positively opaque about that even if they do go on for
> megabytes.

"timedatectl" is a command for configuring and showing various time
settings. You probably mean: how to stop Systemd's NTP service. See "man
timedatectl" or "timedatectl -h". Look for subcommand "set-ntp".

sudo timedatectl set-ntp false

See the current state with just "timedatectl" command. What happens
behind the surface is enabling/disabling service
systemd-timesyncd.service. You can check its status:

systemctl status systemd-timesyncd.service

-- 
/// Teemu Likonen - .-.. https://www.iki.fi/tlikonen/
// OpenPGP: 6965F03973F0D4CA22B9410F0F2CAE0E07608462


signature.asc
Description: PGP signature

Re: strange time problem with bullseye

[tomas]

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!

great :-)

> Now, how do I assure timedatectl stays stopped on a reboot? [...]

I'll have to leave this to others more fluent in systemd-ish.

Cheers
-- 
t


signature.asc
Description: PGP signature

Re: strange time problem with bullseye

[gene heskett]

On 3/7/24 00:22, to...@tuxteam.de wrote:

On Wed, Mar 06, 2024 at 08:06:15PM -0600, John Hasler wrote:

Look at the chronyd settime command and the chrony.conf makestep
directive.  These are intended for your situation.


This from man(8) ntpd:

  -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 off‐
set exceeds the panic threshold, which is 1000 s by default. This
option allows the time to be set to any value without restric‐
tion; however, this can happen only once. If the threshold is ex‐
ceeded 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.

  -G, --force-step-once
Step any initial offset correction..
[...]

Cheers


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? systemd's 
docs are positively opaque about that even if they do go on for 
megabytes. Surprisingly the chrony.conf setting to use my own server 
setup on this machine making me a level 2 ntp server, magically re-appeared.


Seems like it should have a disable option to match the enable but 
playing 50 monkeys didn't find it.


Thanks take care & stay well Tomas.

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

Re: Spam from the list?

[Andy Smith]

Hi,

On Thu, Mar 07, 2024 at 09:44:51AM +0100, Hans wrote:
> --- sninp ---
> 
> Authentication-Results: mail35c50.megamailservers.eu; spf=none 
> smtp.mailfrom=lists.debian.org
> Authentication-Results: mail35c50.megamailservers.eu;
>   dkim=fail reason="signature verification failed" (2048-bit key) 
> header.d=debian.org header.i=@debian.org header.b="pDp/TPD5"
> Return-Path: 
> Received: from bendel.debian.org (bendel.debian.org [82.195.75.100])
>   by mail35c50.megamailservers.eu (8.14.9/8.13.1) with ESMTP id 
> 425I9ZEK112497
>   for ; Tue, 5 Mar 2024 18:09:37 +
> 
> --- snap ---
> 
> White mails get the dkim=pass and spam mails got dkim=fail (as you see above).

A great many legitimate emails will fail DKIM so it is not a great
idea to reject every email that does so. I don't think that you are
going to have a good time using Internet mailing lists while your
mail provider rejects mails with invalid DKIM, so if I were you I'd
work on fixing that rather than trying to get everyone involved to
correctly use DKIM.

In this specific example your problem is that a mail came through
the Debian bug tracking system (which pretends to be the original
sender) and on the way out was DKIm signed by debian.org and then
went through Debian's list servers. Somewhere in there the DKIM
signature was broken.

I don't rate your chances of getting the operators of
bugs.debian.org and lists.debian.org to agree to preserve DKIM since
I know at least some of them are severely opposed to DKIM.

Your mailbox provider really should not be rejecting everything that
has a broken DKIm signature. This email from me will probably have a
broken DKIM signature.

Thanks,
Andy

-- 
https://bitfolk.com/ -- No-nonsense VPS hosting

Aw: Re: very poor nfs performance

[Stefan K]

Hi Ralph,

I just tested it with scp and I got 262MB/s
So it's not a network issue, just a NFS issue, somehow.

best regards
Stefan

> Gesendet: Donnerstag, 07. März 2024 um 11:22 Uhr
> Von: "Ralph Aichinger" 
> An: debian-user@lists.debian.org
> Betreff: Re: very poor nfs performance
>
> On Thu, 2024-03-07 at 10:13 +0100, Stefan K wrote:
> > Hello guys,
> > 
> > I hope someone can help me with my problem.
> > Our NFS performance ist very bad, like ~20MB/s, mountoption looks
> > like that:
> 
> Are both sides agreeing on MTU (using Jumbo frames or not)?
> 
> Have you tested the network with iperf (or simiar), does this happen
> only with NFS or also with other network traffic?
> 
> /ralph
> 
>

Re: Spam from the list?

[Byunghee HWANG]

On Thu, Mar 07, 2024 at 09:44:51AM +0100, Hans wrote:
> Hi all,
> I believe, I found the reason, why mails are marked as spam and others not.
> 
> All spam mails shjow this entry in the header:
> 
> --- sninp ---
> 
> Authentication-Results: mail35c50.megamailservers.eu; spf=none 
> smtp.mailfrom=lists.debian.org
> Authentication-Results: mail35c50.megamailservers.eu;
>   dkim=fail reason="signature verification failed" (2048-bit key) 
> header.d=debian.org header.i=@debian.org header.b="pDp/TPD5"
> Return-Path: 
> Received: from bendel.debian.org (bendel.debian.org [82.195.75.100])
>   by mail35c50.megamailservers.eu (8.14.9/8.13.1) with ESMTP id 
> 425I9ZEK112497
>   for ; Tue, 5 Mar 2024 18:09:37 +
> 
> --- snap ---
> 
> White mails get the dkim=pass and spam mails got dkim=fail (as you see above).
> 
> However, I am not much experienced with DKIM, but as far as I read, it has 
> soemthing to do with key exchanges. 
> 
> But who must exchange keys? I see also bendel.debian.org and a bounce message.
> 
> Can that be the reason, that bendel.debian.org and megameilservers.eu has 
> some 
> problems with the keys?
> 
> On both I can not take a look and have no influence to it, but mayme the 
> admins 
> of bendel.debian.org do know more.
> 
> Thanks for reading this,
> 
> Best regards
> 
> Hans

Well i think that you would be add to whitelist emails from bendel.debian.org. 


Thanks, Byunghee from South Korea

Re: Bullseye installation media nowhere to be found

[Byunghee HWANG]

On Tue, Mar 05, 2024 at 06:36:43AM -0500, Felix Miata wrote:
> It seems as though old-stable and older .isos have ceased to be available, 
> even
> though all the older versions' .debs remain on mirrors.
>  and
>  and
>  have lead me nowhere but to
> 12.5. I feel like there must be obvious I'm missing, as I keep circling back 
> to
> the same places that offer no .isos.
> 
> Why? Kernel panics on 32-bit:
> 
> Communication with that OP is very difficult.
> 
> I wish to test locally a proposed path forward, booting installed system via
> installation media, prior to proposing it. That requires I have the same
> installation media he seems to be tied to, or at least the same major version
> (11), correct? Otherwise, how can I be sure what I tell him to expect is in 
> fact
> what could or should occur?
> -- 
> Evolution as taught in public schools is, like religion,
>   based on faith, not based on science.
> 
>  Team OS/2 ** Reg. Linux User #211409 ** a11y rocks!
> 
> Felix Miata
> 

If you have rare wifi devices, see:
https://cdimage.debian.org/cdimage/unofficial/non-free/cd-including-firmware/archive/11.9.0+nonfree/amd64/iso-cd/


Thanks, Byunghee from South Korea

Re: very poor nfs performance

[Ralph Aichinger]

On Thu, 2024-03-07 at 10:13 +0100, Stefan K wrote:
> Hello guys,
> 
> I hope someone can help me with my problem.
> Our NFS performance ist very bad, like ~20MB/s, mountoption looks
> like that:

Are both sides agreeing on MTU (using Jumbo frames or not)?

Have you tested the network with iperf (or simiar), does this happen
only with NFS or also with other network traffic?

/ralph

Re: Commandline client to lookup MAC vendor

[Ralph Aichinger]

On Thu, 2024-03-07 at 09:52 +, Thomas Pircher wrote:
> On 2024-03-07 09:37, Jonathan Dowland wrote:
> >     $ grep -i ^9009df /usr/share/nmap/nmap-mac-prefixes
> >     9009DF Intel Corporate
> 
> Alternatively, the ieee-data package also contains the OUI database:
> 
>  $ grep -i ^9009df /usr/share/ieee-data/oui.txt
>  9009DF (base 16)    Intel Corporate

Thanks to the both of you. Any idea if one or the other is preferable
or newer?

/ralph

Re: Problema chroot sid

[griera]

Moltes gràcies per l'interès, Alex!

On Wed, 6 Mar 2024 22:53:11 +0100
Alex Muntada  wrote:

> Hola,
> 
> > 2024-03-04 08:20:28 
> > URL:http://deb.debian.org/debian/pool/main/z/zlib/zlib1g_1.3.dfsg-3.1_amd64.deb
> >  [87580/87580] -> 
> > "/srv/chroot/sid//var/cache/apt/archives/partial/zlib1g_1%3a1.3.dfsg-3.1_amd64.deb"
> >  [1]
> > tar: ./usr/lib/x86_64-linux-gnu/libuuid.so.1.3.0: Cannot open: File exists
> > tar: ./usr/lib/x86_64-linux-gnu/libuuid.so.1: Cannot create symlink to 
> > 'libuuid.so.1.3.0': File exists
> > tar: Exiting with failure status due to previous errors
> 
> Ho he tornat a provar ara i l'error era diferent: es queixava
> d'una incompatibilitat entre libssl3t64 i libssl3. Això m'ha
> fet pensar que, essent sid la versió inestable, potser hi ha
> alguna transició en marxa i he trobat això:
> 
> https://release.debian.org/transitions/html/auto-openssl.html

No en se prou com per avaluar tot això i me perdo.

 
> > Els primers cops no me'n vaig adonar d'aquest error. Total que he enviat un 
> > bug:
> > 
> > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1065343
> 
> He vist que han resolt una part, però segueix fallant el
> debootstrap per altres transicions que hi ha en marxa.
> Segurament debootstrap no està pensat per utilitzar-se amb
> sid, encara que s'utilitzi el de backports, perquè instal·la els
> paquets amb dpkg directament enlloc de fer-ho amb apt.
> 
> He provat el mmdebstrap que suggereixen al bug i a mi també
> m'ha funcionat bé (com deia abans, mmdebstrap utilitza apt per
> instal·lar els paquets i aleshores resol millor les dependències
> que debootstrap).

Sí,amb:

sudo mmdebstrap sid /srv/chroot/sid

no hi ha cap problema. Aquesta comanda, que desconeixia, m'ha salvat.

 
> > Vols dir que no utilitzes el debootstrap de bookworm-backports?
> > No ho entenc, perquè si utilitzo el debootstrap de bookworm en
> > lloc del de bookworm-backports a mi me surt el mateix error de
> > "Cannot open: File exists".
> 
> Perquè el problema està a la resolució de dependències que
> comento més amunt en una versió del sistema que és inestable per
> les transicions que hi ha constantment:
> 
> https://release.debian.org/transitions/

Ja, però en un chroot va molt bé per executar aplicacions que tenen problemes 
en la versió estable (en aquest cas, hadbrake, que en el versió estable, al 
gravar els subtítols, els grava doble) o que necessites una versió més actual. 
Sempre estic a estable i acabo instal·lant una sid en un chroot. Per mi, molt 
millor que una màquina virtual.

Gràcies per tota aquesta ajuda i salut!


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

Re: Commandline client to lookup MAC vendor

[Thomas Pircher]

On 2024-03-07 09:37, Jonathan Dowland wrote:

$ grep -i ^9009df /usr/share/nmap/nmap-mac-prefixes
9009DF Intel Corporate


Alternatively, the ieee-data package also contains the OUI database:

$ grep -i ^9009df /usr/share/ieee-data/oui.txt
9009DF (base 16)Intel Corporate

Thomas

Re: Commandline client to lookup MAC vendor

[Jonathan Dowland]

On Thu Mar 7, 2024 at 8:50 AM GMT, Ralph Aichinger wrote:
> Several packages in Debian can somehow (either by embedding it or
> querying it from some common database) display the MAC Vendor
> information of network adapters (derived from hardware addresses). 
>
> One example is nmap, that displays the device vendor when scanning.
>
> Is there some commandline tool doing this directly in Debian? I know
> that there are websites that offer this as a service, but sometimes a
> CLI is more convenient.
>
> Alternatively, and if this information is stored in some shared
> databases, can this be queried e.g. from a Pyhton script? If so, how?

The nmap-common package ships the DB that nmap queries in a plain text
format: /usr/share/nmap/nmap-mac-prefixes

Example

$ ip link show wlp0s20f3 | grep ether
link/ether 90:09:df:ba:0c:cf brd ff:ff:ff:ff:ff:ff
$ grep -i ^9009df /usr/share/nmap/nmap-mac-prefixes
9009DF Intel Corporate


HTH,

-- 
Please do not CC me for listmail.

  Jonathan Dowland
✎j...@debian.org
   https://jmtd.net

very poor nfs performance

[Stefan K]

Hello guys,

I hope someone can help me with my problem.
Our NFS performance ist very bad, like ~20MB/s, mountoption looks like that:
rw,relatime,sync,vers=4.2,rsize=1048576,wsize=1048576,namlen=255,hard,proto=tcp,timeo=600,retrans=2,sec=sys,local_lock=none
The NFS server (debian 12) is a ZFS Fileserver with 40G network connection, 
also the read/write performance is good:
fio --rw=readwrite  --rwmixread=70 --name=test --size=50G --direct=1 
--bsrange=4k-1M --numjobs=30 --group_reporting 
--filename=/zfs_storage/test/asdfg --runtime=600 --time_based
   READ: bw=11.1GiB/s (11.9GB/s), 11.1GiB/s-11.1GiB/s (11.9GB/s-11.9GB/s), 
io=6665GiB (7156GB), run=64-64msec
  WRITE: bw=4875MiB/s (5112MB/s), 4875MiB/s-4875MiB/s (5112MB/s-5112MB/s), 
io=2856GiB (3067GB), run=64-64msec

Only one nfs client(debian 12) is connected via 10G, since we host also 
database files on the nfs share, 'sync'-mountoption is important (more or 
less), but it should still be much faster than 20MB/s

so can somebody tell me whats wrong or what should I change to speed that up?

thanks in advance.
best regards
Stefan

Commandline client to lookup MAC vendor

[Ralph Aichinger]

Hi!

Several packages in Debian can somehow (either by embedding it or
querying it from some common database) display the MAC Vendor
information of network adapters (derived from hardware addresses). 

One example is nmap, that displays the device vendor when scanning.

Is there some commandline tool doing this directly in Debian? I know
that there are websites that offer this as a service, but sometimes a
CLI is more convenient.

Alternatively, and if this information is stored in some shared
databases, can this be queried e.g. from a Pyhton script? If so, how?

TIA
/ralph

Re: Spam from the list?

[Hans]

Hi all,
I believe, I found the reason, why mails are marked as spam and others not.

All spam mails shjow this entry in the header:

--- sninp ---

Authentication-Results: mail35c50.megamailservers.eu; spf=none 
smtp.mailfrom=lists.debian.org
Authentication-Results: mail35c50.megamailservers.eu;
dkim=fail reason="signature verification failed" (2048-bit key) 
header.d=debian.org header.i=@debian.org header.b="pDp/TPD5"
Return-Path: 
Received: from bendel.debian.org (bendel.debian.org [82.195.75.100])
by mail35c50.megamailservers.eu (8.14.9/8.13.1) with ESMTP id 
425I9ZEK112497
for ; Tue, 5 Mar 2024 18:09:37 +

--- snap ---

White mails get the dkim=pass and spam mails got dkim=fail (as you see above).

However, I am not much experienced with DKIM, but as far as I read, it has 
soemthing to do with key exchanges. 

But who must exchange keys? I see also bendel.debian.org and a bounce message.

Can that be the reason, that bendel.debian.org and megameilservers.eu has some 
problems with the keys?

On both I can not take a look and have no influence to it, but mayme the admins 
of bendel.debian.org do know more.

Thanks for reading this,

Best regards

Hans

Re: Firefox et PDF

[Basile Starynkevitch]

On 3/6/24 12:38, ajh-valmer wrote:

On Tuesday 05 March 2024 16:50:44 Thierry wrote:

depuis la mise à jour dans la version 115.8.0esr (testing), je reçois le
message suivant à l'ouverture d'un PDF:
"Votre navigateur ne comprend pas de plugin de lecture de PDF"
Quelqu'un a t'il rencontré ce problème? (pas très gênant par ailleurs
puisqu'il suffit de télécharger le PDF pour le lire)

Désolé, je ne réponds pas au problème,
mais je constate que la version 115.8.0-esr Firefox,
marche mal, elle ne sait pas envoyer des formulaires,
ni faire apparaître des images, se bloque à un moment (ça mouline),
il faut le stopper et le ré-ouvrir...
Alors que Chrome n'a pas du tout ces défauts horripilants.
J'estime que Firefox est buggé.

Personnellement je n'ai aucun problème avec cette version (sur 
Debian/Testing/x86-64). Elle fonctionne correctement et affiche bien des 
PDF (obtenus avec LaTeX)


Librement

--
Basile Starynkevitch 
(only mine opinions / les opinions sont miennes uniquement)
92340 Bourg-la-Reine, France
web page: starynkevitch.net/Basile/
See/voir:   https://github.com/RefPerSys/RefPerSys