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

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

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