Re: [bullseye] r-cran-ggplot2 depends on missing libpq5 v13.8

[Loris Bennett]

David Wright  writes:

> On Mon 13 Mar 2023 at 07:38:50 (+0100), Loris Bennett wrote:
>> David Wright  writes:
>> > On Fri 10 Mar 2023 at 10:10:48 (+0100), Loris Bennett wrote:
>> >> 
>> >> I am on bullseye and am trying to install the package r-cran-ggplot2.
>> >> This fails with 
>> >> 
>> >>   E: Failed to fetch
>> >>   
>> >> http://deb.debian.org/debian/pool/main/p/postgresql-13/libpq5_13.8-0%2bdeb11u1_amd64.deb
>> >>   404  Not Found [IP: 146.75.122.132 80] 
>> >> 
>> >> (full output below).
>> >> 
>> >> There seems to be a dependency on libpq5 version 13.8 whereas the
>> >> version available for bullseye is 13.9.
>> >> 
>> >> Any ideas how to solve this?
>> >
>> > Try:
>> >
>> > # apt-get update
>> >
>> > first.
>> 
>> I had already done this.  It does not solve the problem.
>
> OK, forget all the r-cran stuff for the moment.
> The current version of libpq5 is:
>
>   $ dpkg -l | grep libpq5
>   ii  libpq5:amd64  13.9-0+deb11u1  amd64  PostgreSQL C client library
>   $ 
>
> and you don't have libpq5 installed, so what do you get from this?
>
>   # apt-get install libpq5

  root:~# apt-get install libpq5
  Reading package lists... Done
  Building dependency tree... Done
  Reading state information... Done
  The following NEW packages will be installed:
libpq5
  0 upgraded, 1 newly installed, 0 to remove and 0 not upgraded.
  Need to get 180 kB of archives.
  After this operation, 805 kB of additional disk space will be used.
  Err:1 http://deb.debian.org/debian bullseye/main amd64 libpq5 amd64 
13.8-0+deb11u1
404  Not Found [IP: 146.75.118.132 80]
  E: Failed to fetch 
http://deb.debian.org/debian/pool/main/p/postgresql-13/libpq5_13.8-0%2bdeb11u1_amd64.deb
  404  Not Found [IP: 146.75.118.132 80]
  E: Unable to fetch some archives, maybe run apt-get update or try with 
--fix-missing?

> If that fails, I think we need to see your /etc/apt/sources.list
> and anything in /etc/apt/sources.list.d/*

  root:~# cat /etc/apt/sources.list
  # See https://wiki.debian.org/SourcesList for more information.
  deb http://deb.debian.org/debian bullseye main contrib non-free
  deb-src http://deb.debian.org/debian bullseye main contrib non-free

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

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

So relative to the original 'source.list' I just added 'contrib' and
'non-free'.  I have nothing in 'sources.list.d':

  root:~# ll /etc/apt/sources.list.d
  total 0

Cheers,

Loris

-- 
This signature is currently under constuction.

Re: Bookworm system randomly not responding (was Re: Bookworm system not responding on high memory usage)

[Anssi Saari]

Xiyue Deng  writes:

> As this system has been running Bullseye for a few years with zero
> problem, I'm hopeful this should work for Bookworm as well.  If you have
> anything in mind that may worth a try please feel free to share.  The
> more ideas the better.

To me the interesting question is, does the problem disappear if you go
back to Bullseye? If not then it's likely a hardware problem.

Re: Debian 12 IPv6 client?

[David Wright]

On Tue 14 Mar 2023 at 12:29:22 (+0800), jeremy ardley wrote:
> I am testing the alpha 2 release of Debian 12
> (I'm quite annoyed they have done away with /var/log/syslog)
> 
> My system is "pure" debian 12 and was net installed a few minutes
> before my checks. Nothing was changed from the original install.
> 
> My problem today is identifying what bit of the system is getting the
> IPv6 address. I can find nothing in journalctl

[ removed the typo ]

> cat /etc.network/interfaces
> # This file describes the network interfaces available on your system
> # and how to activate them. For more information, see interfaces(5).
> 
> source /etc/network/interfaces.d/*
> 
> # The loopback network interface
> auto lo
> iface lo inet loopback
> 
> # The primary network interface
> allow-hotplug enp0s3
> iface enp0s3 inet dhcp
> # This is an autoconfigured IPv6 interface
> iface enp0s3 inet6 auto
   ↑↑

I'm not very familiar with interfaces nowadays, but that looks
as if it's asking for enp0s3 to be autoconfigured with an IPv6
address. I thought that one got an IPv6 link address autoconfigured
anyway—I certainly do.

Did the debian-installer write that line (and comment)?

> Checking dhclient I see
> 
> ps ax | grep dhcl
>     354 ?    Ss 0:00 dhclient -4 -v -i -pf
> /run/dhclient.enp0s3.pid -lf /var/lib/dhcp/dhclient.enp0s3.leases -I
> -df /var/lib/dhcp/dhclient6.enp0s3.leases enp0s3
>     579 pts/0    S+ 0:00 grep dhcl
> 
> So no dhclient -6 running.
> 
> root@debian12:/etc/network# journalctl | grep -i ipv6
> Mar 14 11:48:25 debian12 kernel: Segment Routing with IPv6
> Mar 14 11:48:25 debian12 kernel: In-situ OAM (IOAM) with IPv6
> Mar 14 11:48:25 debian12 kernel: mip6: Mobile IPv6
> Mar 14 11:48:26 debian12 kernel: IPv6: ADDRCONF(NETDEV_CHANGE):
> enp0s3: link becomes ready
> Mar 14 12:04:46 debian12 kernel: Segment Routing with IPv6
> Mar 14 12:04:46 debian12 kernel: In-situ OAM (IOAM) with IPv6
> Mar 14 12:04:46 debian12 kernel: mip6: Mobile IPv6
> Mar 14 12:04:48 debian12 kernel: IPv6: ADDRCONF(NETDEV_CHANGE):
> enp0s3: link becomes ready
> 
> 
> My question remains. What is getting the IPv6 address and how can I
> make configuration changes if required?

What's the output from:

  $ ip a

Mine (skipping lo):

  2: enp3s0:  mtu 1500 qdisc pfifo_fast state 
UP group default qlen 1000
  link/ether a4:01:23:45:67:89 brd ff:ff:ff:ff:ff:ff
  inet 192.168.1.14/24 brd 192.168.1.255 scope global dynamic enp3s0
 valid_lft 74247sec preferred_lft 74247sec
  inet6 fe80::a601:23ff:fe45:6789/64 scope link  ← this here
 valid_lft forever preferred_lft forever

Cheers,
David.

Re: Debian 12 IPv6 client?

[Jeremy Ardley]

On 14/3/23 12:29, jeremy ardley wrote:

I am testing the alpha 2 release of Debian 12
(I'm quite annoyed they have done away with /var/log/syslog)

My system is "pure" debian 12 and was net installed a few minutes 
before my checks. Nothing was changed from the original install.


My problem today is identifying what bit of the system is getting the 
IPv6 address. I can find nothing in journalctl


The networking  is pure systemd networkd.service controlled


Correction. I mistyped above. My system uses the systemd networking.service

root@debian12:/etc/network# systemctl status networking
● networking.service - Raise network interfaces
 Loaded: loaded (/lib/systemd/system/networking.service; enabled; 
preset: enabled)

 Active: active (exited) since Tue 2023-03-14 12:04:46 AWST; 23min ago
   Docs: man:interfaces(5)
    Process: 299 ExecStart=/sbin/ifup -a --read-environment 
(code=exited, status=0/SUCCESS)
    Process: 374 ExecStart=/bin/sh -c if [ -f 
/run/network/restart-hotplug ]; then /sbin/ifup -a --read-environment 
--allow=hotplug; fi (code=exited, status=0/SUCCESS)

   Main PID: 374 (code=exited, status=0/SUCCESS)
    CPU: 15ms

Mar 14 12:04:46 debian12 systemd[1]: Starting networking.service - Raise 
network interfaces...
Mar 14 12:04:46 debian12 systemd[1]: Finished networking.service - Raise 
network interfaces.


--
Jeremy
(Lists)

Debian 12 IPv6 client?

[jeremy ardley]

I am testing the alpha 2 release of Debian 12
(I'm quite annoyed they have done away with /var/log/syslog)

My system is "pure" debian 12 and was net installed a few minutes before 
my checks. Nothing was changed from the original install.


My problem today is identifying what bit of the system is getting the 
IPv6 address. I can find nothing in journalctl


The networking  is pure systemd networkd.service controlled

root@debian12:/etc/network# systemctl status networking
● networking.service - Raise network interfaces
 Loaded: loaded (/lib/systemd/system/networking.service; enabled; 
preset: enabled)

 Active: active (exited) since Tue 2023-03-14 12:04:46 AWST; 23min ago
   Docs: man:interfaces(5)
    Process: 299 ExecStart=/sbin/ifup -a --read-environment 
(code=exited, status=0/SUCCESS)
    Process: 374 ExecStart=/bin/sh -c if [ -f 
/run/network/restart-hotplug ]; then /sbin/ifup -a --read-environment 
--allow=hotplug; fi (code=exited, status=0/SUCCESS)

   Main PID: 374 (code=exited, status=0/SUCCESS)
    CPU: 15ms

Mar 14 12:04:46 debian12 systemd[1]: Starting networking.service - Raise 
network interfaces...
Mar 14 12:04:46 debian12 systemd[1]: Finished networking.service - Raise 
network interfaces.



cat /etc.network/interfaces
# This file describes the network interfaces available on your system
# and how to activate them. For more information, see interfaces(5).

source /etc/network/interfaces.d/*

# The loopback network interface
auto lo
iface lo inet loopback

# The primary network interface
allow-hotplug enp0s3
iface enp0s3 inet dhcp
# This is an autoconfigured IPv6 interface
iface enp0s3 inet6 auto

Checking dhclient I see

ps ax | grep dhcl
    354 ?    Ss 0:00 dhclient -4 -v -i -pf 
/run/dhclient.enp0s3.pid -lf /var/lib/dhcp/dhclient.enp0s3.leases -I -df 
/var/lib/dhcp/dhclient6.enp0s3.leases enp0s3

    579 pts/0    S+ 0:00 grep dhcl

So no dhclient -6 running.

root@debian12:/etc/network# journalctl | grep -i ipv6
Mar 14 11:48:25 debian12 kernel: Segment Routing with IPv6
Mar 14 11:48:25 debian12 kernel: In-situ OAM (IOAM) with IPv6
Mar 14 11:48:25 debian12 kernel: mip6: Mobile IPv6
Mar 14 11:48:26 debian12 kernel: IPv6: ADDRCONF(NETDEV_CHANGE): enp0s3: 
link becomes ready

Mar 14 12:04:46 debian12 kernel: Segment Routing with IPv6
Mar 14 12:04:46 debian12 kernel: In-situ OAM (IOAM) with IPv6
Mar 14 12:04:46 debian12 kernel: mip6: Mobile IPv6
Mar 14 12:04:48 debian12 kernel: IPv6: ADDRCONF(NETDEV_CHANGE): enp0s3: 
link becomes ready



My question remains. What is getting the IPv6 address and how can I make 
configuration changes if required?





Jeremy

Re: [SOLVED?] Re: BIND: managed-keys-zone: Unable to fetch DNSKEY set '.': timed out

[local10]

Mar 13, 2023, 23:33 by jer...@ardley.org:

> You may be happy to learn you can't even install it as a separate package any 
> more.
>
> apt  install --reinstall systemd-resolved
> Reading package lists... Done
> Building dependency tree... Done
> Reading state information... Done
> Package systemd-resolved is not available, but is referred to by another 
> package.
> This may mean that the package is missing, has been obsoleted, or
> is only available from another source
> ...
>
> So the mystery is how it gets onto a system using a standard install and 
> which package it comes from now and what is done with any presets
>


On Debian 12 Bookworm it could be done:

# aptitude show systemd-resolved
Package: systemd-resolved   
Version: 252.6-1
New: yes
State: not installed
...


# aptitude install systemd-resolved --simulate
The following NEW packages will be installed:
  libnss-myhostname{a} libnss-resolve{a} systemd-resolved
0 packages upgraded, 3 newly installed, 0 to remove and 0 not upgraded.
Need to get 484 kB of archives. After unpacking 1,234 kB will be used.

Note: Using 'Simulate' mode.
Do you want to continue? [Y/n/?] n
Abort.


Regards,

Re: real debian or true debian?

[Jeremy Ardley]

On 14/3/23 07:55, rhkra...@gmail.com wrote:

On Sunday, March 12, 2023 09:02:26 PM cor...@free.fr wrote:

When such a debian (the digital product) is authentic, should we say it
"real debian" or "true debian"?

I am not sure about this statement.

My guess is that Corey is a French speaker, and is unsure about the best way
to (simply) indicate that a Debian installation is "authentic" (meaning not
adulterated in some way, not a "Frankendebian: for instance).

I am not sure what to tell him, my thought is something using the word
canonical and with a Debian version specification, e.g. canonical Debian
Bullseye.

But, surely there is a simpler word than canonical (and maybe canonical isn't
quite the right word anyway, in this context).

Others must have better ideas ;-)


The response by an artificial intelligence system that cannot be named:

***

The term commonly used to indicate that a Debian installation is 
"authentic" is "pure".


***

--
Jeremy
(Lists)

Re: real debian or true debian?

[rhkramer]

On Sunday, March 12, 2023 09:02:26 PM cor...@free.fr wrote:
> When such a debian (the digital product) is authentic, should we say it
> "real debian" or "true debian"?
> 
> I am not sure about this statement.

My guess is that Corey is a French speaker, and is unsure about the best way 
to (simply) indicate that a Debian installation is "authentic" (meaning not 
adulterated in some way, not a "Frankendebian: for instance).

I am not sure what to tell him, my thought is something using the word 
canonical and with a Debian version specification, e.g. canonical Debian 
Bullseye.

But, surely there is a simpler word than canonical (and maybe canonical isn't 
quite the right word anyway, in this context).

Others must have better ideas ;-)

-- 
rhk 

(sig revised 20230312 -- modified first paragraph, some other irrelevant 
wordsmithing)

| No entity has permission to use this email to train an AI. 

If you reply: snip, snip, and snip again; leave attributions; avoid HTML; 
avoid top posting; and keep it "on list".  (Oxford comma (and semi-colon) 
included at no charge.)  If you revise the topic, change the Subject: line.  
If you change the topic, start a new thread.

Writing is often meant for others to read and understand (legal documents 
excepted?) -- make it easier for your reader by various means, including 
liberal use of whitespace (short paragraphs, separated by whitespace / blank 
lines) and minimal use of (obscure?) jargon, abbreviations, acronyms, and 
references.

If someone has already responded to a question, decide whether any response 
you add will be helpful or not ...

A picture is worth a thousand words.  A video (or "audio"): not so much -- 
divide by 10 for each minute of video (or audio) or create a transcript and 
edit it to 10% of the original.

A speaker who uses ahhs, ums, or such may have a real physical or mental 
disability, or may be showing disrespect for his listeners by not properly 
preparing in advance and thinking before speaking. (That speaker might have 
been "trained" to do this by being interrupted often if he pauses.)  (Remember 
Cicero who did not have enough time to write a short missive.)

A radio (or TV) station which broadcasts speakers with high pitched voices (or 
very low pitched / gravelly voices) (which older people might not be able to 
hear properly) disrespects its listeners.   Likewise if it broadcasts 
extraneous or disturbing sounds (like gunfire or crying), or broadcasts 
speakers using their native language (with or without an overdubbed 
translation).

A person who writes a sig this long probably has issues and disrespects (and 
offends) a large number of readers. ;-)
'

Re: [SOLVED?] Re: BIND: managed-keys-zone: Unable to fetch DNSKEY set '.': timed out

[Greg Wooledge]

On Tue, Mar 14, 2023 at 07:33:00AM +0800, Jeremy Ardley wrote:
> So the mystery is how it gets onto a system using a standard install and
> which package it comes from now and what is done with any presets

unicorn:~$ dpkg -S systemd-resolved
systemd: /usr/share/man/man8/systemd-resolved.8.gz
systemd: /lib/systemd/systemd-resolved
systemd: /lib/systemd/system/systemd-resolved.service
systemd: /usr/share/man/man8/systemd-resolved.service.8.gz

It's installed by default, but it's not ENABLED by default.

Re: [SOLVED?] Re: BIND: managed-keys-zone: Unable to fetch DNSKEY set '.': timed out

[Jeremy Ardley]

On 14/3/23 07:23, Greg Wooledge wrote:


I have not to this day figured out what "vendor preset" means here.

Mine shows the same as yours -- "disabled; vendor preset: enabled".

All I care about is the part that says "disabled".  That's the actual
state.


You may be happy to learn you can't even install it as a separate 
package any more.


apt  install --reinstall systemd-resolved
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
Package systemd-resolved is not available, but is referred to by another 
package.

This may mean that the package is missing, has been obsoleted, or
is only available from another source

It's on the test VM I built recently so it comes from somewhere

The general documentation says that if you install it as a package then 
it will rewrite various config files to take over the machine DNS.


So the mystery is how it gets onto a system using a standard install and 
which package it comes from now and what is done with any presets


--
Jeremy
(Lists)

Re: [SOLVED?] Re: BIND: managed-keys-zone: Unable to fetch DNSKEY set '.': timed out

[Greg Wooledge]

On Tue, Mar 14, 2023 at 07:04:02AM +0800, Jeremy Ardley wrote:
> I replicated your test above and it seems your listing has been accidentally
> truncated...

Pipe it through cat to avoid the "left/right scrolling" crap.

> jeremy@testldap:~$ systemctl status systemd-resolved
> ● systemd-resolved.service - Network Name Resolution
>  Loaded: loaded (/lib/systemd/system/systemd-resolved.service; disabled;
> vendor preset: enabled)
>  Active: inactive (dead)
>    Docs: man:systemd-resolved.service(8)
>  man:org.freedesktop.resolve1(5)
> https://www.freedesktop.org/wiki/Software/systemd/writing-network-configuration-managers
> https://www.freedesktop.org/wiki/Software/systemd/writing-resolver-clients
> 
> It would seem the debian default is enabled? See vendor preset below.

I have not to this day figured out what "vendor preset" means here.

Mine shows the same as yours -- "disabled; vendor preset: enabled".

All I care about is the part that says "disabled".  That's the actual
state.

Re: [SOLVED?] Re: BIND: managed-keys-zone: Unable to fetch DNSKEY set '.': timed out

[Jeremy Ardley]

On 14/3/23 06:34, Greg Wooledge wrote:

On Tue, Mar 14, 2023 at 06:23:09AM +0800, Jeremy Ardley wrote:

FYI systed-resolved is the inbuilt debian caching DNS server which may be
enabled by default.

It is NOT enabled by default.

unicorn:~$ systemctl status systemd-resolved
● systemd-resolved.service - Network Name Resolution
  Loaded: loaded (/lib/systemd/system/systemd-resolved.service; disabled; 
ve>
  Active: inactive (dead)
Docs: man:systemd-resolved.service(8)
  man:org.freedesktop.resolve1(5)
  
https://www.freedesktop.org/wiki/Software/systemd/writing-network->
  
https://www.freedesktop.org/wiki/Software/systemd/writing-resolver>


I replicated your test above and it seems your listing has been 
accidentally truncated...


jeremy@testldap:~$ systemctl status systemd-resolved
● systemd-resolved.service - Network Name Resolution
 Loaded: loaded (/lib/systemd/system/systemd-resolved.service; 
disabled; vendor preset: enabled)

 Active: inactive (dead)
   Docs: man:systemd-resolved.service(8)
 man:org.freedesktop.resolve1(5)
https://www.freedesktop.org/wiki/Software/systemd/writing-network-configuration-managers
https://www.freedesktop.org/wiki/Software/systemd/writing-resolver-clients

It would seem the debian default is enabled? See vendor preset below.

Loaded: loaded (/lib/systemd/system/systemd-resolved.service; disabled; 
vendor preset: enabled)


--
Jeremy
(Lists)

Re: [SOLVED?] Re: BIND: managed-keys-zone: Unable to fetch DNSKEY set '.': timed out

[Jeremy Ardley]

On 14/3/23 06:34, Greg Wooledge wrote:

On Tue, Mar 14, 2023 at 06:23:09AM +0800, Jeremy Ardley wrote:

FYI systed-resolved is the inbuilt debian caching DNS server which may be
enabled by default.

It is NOT enabled by default.


It is if you are using NetworkManager

--
Jeremy
(Lists)

Re: [SOLVED?] Re: BIND: managed-keys-zone: Unable to fetch DNSKEY set '.': timed out

[Jeremy Ardley]

On 14/3/23 06:23, Jeremy Ardley wrote:


I had a signed DNS error in a similar configuration using a bind 
authoritive and caching server. It turned out it was systemd-resolved 
interfering and/or replacing part of the DNS chain


FYI systed-resolved is the inbuilt debian caching DNS server which may 
be enabled by default. If you run that you don't need a bind9 caching 
name server


What does this report ?

systemctl status systemd-resolved

If  there is anything there at all, check logs. You may find something

Also FYI you can run bind9 and systemd-resolved at the same time and set 
bind9 to use systemd-resolved as forwarder



|options { directory "/var/cache/bind"; // Use systemd-resolved as a DNS 
resolver forwarders { 127.0.0.53 port 53; }; dnssec-validation auto; 
auth-nxdomain no; # conform to RFC1035 ... Its probably a good idea to 
not be too keen on dnssec validation - as above. |

--
Jeremy
(Lists)

Re: [SOLVED?] Re: BIND: managed-keys-zone: Unable to fetch DNSKEY set '.': timed out

[Greg Wooledge]

On Tue, Mar 14, 2023 at 06:23:09AM +0800, Jeremy Ardley wrote:
> FYI systed-resolved is the inbuilt debian caching DNS server which may be
> enabled by default.

It is NOT enabled by default.

unicorn:~$ systemctl status systemd-resolved
● systemd-resolved.service - Network Name Resolution
 Loaded: loaded (/lib/systemd/system/systemd-resolved.service; disabled; ve>
 Active: inactive (dead)
   Docs: man:systemd-resolved.service(8)
 man:org.freedesktop.resolve1(5)
 https://www.freedesktop.org/wiki/Software/systemd/writing-network->
 https://www.freedesktop.org/wiki/Software/systemd/writing-resolver>

Re: [SOLVED?] Re: BIND: managed-keys-zone: Unable to fetch DNSKEY set '.': timed out

[Greg Wooledge]

On Mon, Mar 13, 2023 at 11:14:20PM +0100, local10 wrote:
> Strangely, the issue resolved itself without me having to do anything. Am 
> really puzzled as to what it was. Perhaps the internet provider suddenly 
> started to block DNS queries but then allowed them again? If so, why did 
> dig's message say that there was "communications error to 127.0.0.1#53: timed 
> out"? It really gives an impression that dig was failing to connect 127.0.0.1 
> port 53, on which bind was running.
> 
> # dig www.yahoo.com 
> ;; communications error to 127.0.0.1#53: timed out
> ;; communications error to 127.0.0.1#53: timed out
> ...
> 
> Maybe someone will shed some light on this.

UDP doesn't have a "connection".  The client sends a datagram (a one-way
message) to the UDP service, and then waits to receive a reply.

If the UDP service in turn sends a datagram to a third party, and waits
for a reply, but never receives one... and thus never responds to the
original client... then all the client knows is that it never got a
response.  It doesn't know why.

Re: [SOLVED?] Re: BIND: managed-keys-zone: Unable to fetch DNSKEY set '.': timed out

[Jeremy Ardley]

On 14/3/23 06:14, local10 wrote:


Strangely, the issue resolved itself without me having to do anything. Am really puzzled 
as to what it was. Perhaps the internet provider suddenly started to block DNS queries 
but then allowed them again? If so, why did dig's message say that there was 
"communications error to 127.0.0.1#53: timed out"? It really gives an 
impression that dig was failing to connect 127.0.0.1 port 53, on which bind was running.

# dig www.yahoo.com 
;; communications error to 127.0.0.1#53: timed out
;; communications error to 127.0.0.1#53: timed out
...

Maybe someone will shed some light on this.

Thanks to everyone who responded.



I had a signed DNS error in a similar configuration using a bind 
authoritive and caching server. It turned out it was systemd-resolved 
interfering and/or replacing part of the DNS chain


FYI systed-resolved is the inbuilt debian caching DNS server which may 
be enabled by default. If you run that you don't need a bind9 caching 
name server


What does this report ?

systemctl status systemd-resolved

If  there is anything there at all, check logs. You may find something

--
Jeremy
(Lists)

Re: [SOLVED?] BIND: managed-keys-zone: Unable to fetch DNSKEY set '.': timed out

[Casey Deccio]

> On Mar 13, 2023, at 4:14 PM, local10  wrote:
> 
> Mar 13, 2023, 21:42 by recovery...@enotuniq.net:
> 
>> Well, it was worth to check it.
>> 
>> 
>> Next idea is somewhat more complicated.
>> 
>> Install tcpdump.
>> Run:
>> tcpdump -pni any -s0 -w /tmp/dns.pcap -c 30 udp port 53 or tcp port 53
>> Bounce BIND, wait for a minute at least.
>> Do some DNS queries. One or two will do.
>> Interrupt tcpdump unless it completes by itself.
>> Post dns.pcap.
>> 
> 
> 
> Strangely, the issue resolved itself without me having to do anything. Am 
> really puzzled as to what it was. Perhaps the internet provider suddenly 
> started to block DNS queries but then allowed them again?

Hard to tell without further data, but it's possible.

> If so, why did dig's message say that there was "communications error to 
> 127.0.0.1#53: timed out"? It really gives an impression that dig was failing 
> to connect 127.0.0.1 port 53, on which bind was running.
> 
> # dig www.yahoo.com 
> ;; communications error to 127.0.0.1#53: timed out
> ;; communications error to 127.0.0.1#53: timed out
> ...
> 
> Maybe someone will shed some light on this.

This one is a little misleading.  The fact is that BIND tries really hard to 
resolve your name, trying all sorts of alternate servers and fallbacks to 
account for timeouts, DNSSEC validation failures, and more.  Sometimes that can 
take a really long time.  In one of the outputs you provided previously, you 
showed "timed out" followed by SERVFAIL.  Those are symptoms of this behavior: 
first query times out with resolver trying things and second query returned the 
cached (SERVFAIL) failure.

Casey

[SOLVED?] Re: BIND: managed-keys-zone: Unable to fetch DNSKEY set '.': timed out

[local10]

Mar 13, 2023, 21:42 by recovery...@enotuniq.net:

> Well, it was worth to check it.
>
>
> Next idea is somewhat more complicated.
>
> Install tcpdump.
> Run:
> tcpdump -pni any -s0 -w /tmp/dns.pcap -c 30 udp port 53 or tcp port 53
> Bounce BIND, wait for a minute at least.
> Do some DNS queries. One or two will do.
> Interrupt tcpdump unless it completes by itself.
> Post dns.pcap.
>


Strangely, the issue resolved itself without me having to do anything. Am 
really puzzled as to what it was. Perhaps the internet provider suddenly 
started to block DNS queries but then allowed them again? If so, why did dig's 
message say that there was "communications error to 127.0.0.1#53: timed out"? 
It really gives an impression that dig was failing to connect 127.0.0.1 port 
53, on which bind was running.

# dig www.yahoo.com 
;; communications error to 127.0.0.1#53: timed out
;; communications error to 127.0.0.1#53: timed out
...

Maybe someone will shed some light on this.

Thanks to everyone who responded.

Re: BIND: managed-keys-zone: Unable to fetch DNSKEY set '.': timed out

[Reco]

Hi.

On Mon, Mar 13, 2023 at 08:53:35PM +0100, local10 wrote:
> Mar 13, 2023, 12:06 by recovery...@enotuniq.net:
> 
> > Looks correct, assuming that the contents of the key start with AwEAAaz
> > and end with V74bU=.
> >
> > 
> > Look at /usr/share/dns/root.key. Compare its contents with
> > /etc/bind/bind.keys. Replace the latter if needed.
> >
> > "dpkg-reconfigure -plow bind9" is probably more preferred way of doing
> > it.
> >
> 
> They keys in the "/etc/bind/bind.keys" and "/usr/share/dns/root.key" are 
> identical:

Well, it was worth to check it.


Next idea is somewhat more complicated.

Install tcpdump.
Run:
tcpdump -pni any -s0 -w /tmp/dns.pcap -c 30 udp port 53 or tcp port 53
Bounce BIND, wait for a minute at least.
Do some DNS queries. One or two will do.
Interrupt tcpdump unless it completes by itself.
Post dns.pcap.

Reco

Re: BIND: managed-keys-zone: Unable to fetch DNSKEY set '.': timed out

[local10]

Mar 13, 2023, 11:50 by mv...@free.fr:

> Did you check memory and disk space as suggested by jeremy ?
>

There's plenty of free RAM (4GB) and disk space (hundreds of GBs).

Regards,

Re: BIND: managed-keys-zone: Unable to fetch DNSKEY set '.': timed out

[local10]

Mar 13, 2023, 14:11 by ca...@deccio.net:

> Based on what I saw in the logs, your resolver is having trouble reaching the 
> internet.  It shows problems with both the priming query (./NS) and the trust 
> query (./DNSKEY).  Could you try running the following?
>
> $ dig +norec @198.41.0.4 . NS
> $ dig +norec @2001:503:ba3e::2:30 . NS
> $ dig +norec @198.41.0.4 . DNSKEY
> $ dig +norec @2001:503:ba3e::2:30 . DNSKEY
>
> These manually send the same queries to the internet that your resolver is 
> attempting.
>
> Cheers,
> Casey
>

$ dig +norec @198.41.0.4 . NS

; <<>> DiG 9.18.12-1-Debian <<>> +norec @198.41.0.4 . NS
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 19016
;; flags: qr aa; QUERY: 1, ANSWER: 13, AUTHORITY: 0, ADDITIONAL: 27

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;.  IN  NS

;; ANSWER SECTION:
.   518400  IN  NS  e.root-servers.net.
.   518400  IN  NS  h.root-servers.net.
.   518400  IN  NS  l.root-servers.net.
.   518400  IN  NS  i.root-servers.net.
.   518400  IN  NS  a.root-servers.net.
.   518400  IN  NS  d.root-servers.net.
.   518400  IN  NS  c.root-servers.net.
.   518400  IN  NS  b.root-servers.net.
.   518400  IN  NS  j.root-servers.net.
.   518400  IN  NS  k.root-servers.net.
.   518400  IN  NS  g.root-servers.net.
.   518400  IN  NS  m.root-servers.net.
.   518400  IN  NS  f.root-servers.net.

;; ADDITIONAL SECTION:
e.root-servers.net. 518400  IN  A   192.203.230.10
e.root-servers.net. 518400  IN      2001:500:a8::e
h.root-servers.net. 518400  IN  A   198.97.190.53
h.root-servers.net. 518400  IN      2001:500:1::53
l.root-servers.net. 518400  IN  A   199.7.83.42
l.root-servers.net. 518400  IN      2001:500:9f::42
i.root-servers.net. 518400  IN  A   192.36.148.17
i.root-servers.net. 518400  IN      2001:7fe::53
a.root-servers.net. 518400  IN  A   198.41.0.4
a.root-servers.net. 518400  IN      2001:503:ba3e::2:30
d.root-servers.net. 518400  IN  A   199.7.91.13
d.root-servers.net. 518400  IN      2001:500:2d::d
c.root-servers.net. 518400  IN  A   192.33.4.12
c.root-servers.net. 518400  IN      2001:500:2::c
b.root-servers.net. 518400  IN  A   199.9.14.201
b.root-servers.net. 518400  IN      2001:500:200::b
j.root-servers.net. 518400  IN  A   192.58.128.30
j.root-servers.net. 518400  IN      2001:503:c27::2:30
k.root-servers.net. 518400  IN  A   193.0.14.129
k.root-servers.net. 518400  IN      2001:7fd::1
g.root-servers.net. 518400  IN  A   192.112.36.4
g.root-servers.net. 518400  IN      2001:500:12::d0d
m.root-servers.net. 518400  IN  A   202.12.27.33
m.root-servers.net. 518400  IN      2001:dc3::35
f.root-servers.net. 518400  IN  A   192.5.5.241
f.root-servers.net. 518400  IN      2001:500:2f::f

;; Query time: 43 msec
;; SERVER: 198.41.0.4#53(198.41.0.4) (UDP)
;; WHEN: Mon Mar 13 15:54:28 EDT 2023
;; MSG SIZE  rcvd: 811


# Note that I'm running bind with "-4" option, that is, IPv4 only
$ dig +norec @2001:503:ba3e::2:30 . NS
;; UDP setup with 2001:503:ba3e::2:30#53(2001:503:ba3e::2:30) for . failed: 
network unreachable.
;; UDP setup with 2001:503:ba3e::2:30#53(2001:503:ba3e::2:30) for . failed: 
network unreachable.
;; UDP setup with 2001:503:ba3e::2:30#53(2001:503:ba3e::2:30) for . failed: 
network unreachable.



$ dig +norec @198.41.0.4 . DNSKEY

; <<>> DiG 9.18.12-1-Debian <<>> +norec @198.41.0.4 . DNSKEY
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 60299
;; flags: qr aa; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1472
;; QUESTION SECTION:
;.  IN  DNSKEY

;; ANSWER SECTION:
.   172800  IN  DNSKEY  256 3 8 
AwEAAcVnO2jZFx4756Rb/yAhJnsl72eemsObU43nclmXwqdJlp+kC5WQ 
jGYkqLT5xkaUCPhkr4NKLLrIBZXeSGazc6gx/yrrMtUpXcQvax6kfDJP 
Tu974OmeEbtjyyP7ZG5tUfSwNWt/4EuxDNmZTESG8jU0ZLjYIB11pK0g 
SXQbMVPyIyGtFGHMPx6UxWn6zUzpECWRFbqEvkA6Y13zeJ1jG2Rki/zs 
7a/o13FTl/kI9013Eh6l6Kc2zxbc14GS8fpM0/xQIrZZyeiXj/2C4Rcs 
PeqWuNj9m0qSQrbrCZtLHb20U8x1uue4iwSX9y7LpwZd6vjYd1d6dgBa 1Xxgc/TC+m8=
.   172800  IN  DNSKEY  257 3 8 
AwEAAaz/tAm8yTn4Mfeh5eyI96WSVexTBAvkMgJzkKTOiW1vkIbzxeF3 
+/4RgWOq7HrxRixHlFlExOLAJr5emLvN

Re: BIND: managed-keys-zone: Unable to fetch DNSKEY set '.': timed out

[local10]

Mar 13, 2023, 12:06 by recovery...@enotuniq.net:

> Looks correct, assuming that the contents of the key start with AwEAAaz
> and end with V74bU=.
>
> 
> Look at /usr/share/dns/root.key. Compare its contents with
> /etc/bind/bind.keys. Replace the latter if needed.
>
> "dpkg-reconfigure -plow bind9" is probably more preferred way of doing
> it.
>

They keys in the "/etc/bind/bind.keys" and "/usr/share/dns/root.key" are 
identical:

# cat /etc/bind/bind.keys
...
trust-anchors {
    # This key (20326) was published in the root zone in 2017.
    . initial-key 257 3 8 
"AwEAAaz/tAm8yTn4Mfeh5eyI96WSVexTBAvkMgJzkKTOiW1vkIbzxeF3
    +/4RgWOq7HrxRixHlFlExOLAJr5emLvN7SWXgnLh4+B5xQlNVz8Og8kv
    ArMtNROxVQuCaSnIDdD5LKyWbRd2n9WGe2R8PzgCmr3EgVLrjyBxWezF
    0jLHwVN8efS3rCj/EWgvIWgb9tarpVUDK/b58Da+sqqls3eNbuv7pr+e
    oZG+SrDK6nWeL3c6H5Apxz7LjVc1uTIdsIXxuOLYA4/ilBmSVIzuDWfd
    RUfhHdY6+cn8HFRm+2hM8AnXGXws9555KrUB5qihylGa8subX2Nn6UwN
    R1AkUTV74bU=";
};


Regards,

Re: Grub bug on Debian 11

[davidson]

On Mon, 13 Mar 2023 Mario Marietto wrote:

Hello to every Debian user.

[elided: Mario Marietto's apology for posting the following question
off-topic in another thread]


"I've just installed Debian 11
and I see that it is affected by the bug
explained here :

https://bugs.launchpad.net/oem-priority/+bug/1842320

I see that the bug has been fixed on Ubuntu. Do you confirm that,to
fix it,I just need to install the package
"grub-efi-amd64_2.06-2ubuntu14.1_amd64.deb" with the command "dpkg
-i grub-efi-amd64_2.06-2ubuntu14.1_amd64.deb" on Debian 11 or do I
just need to do something else ?

[elided: remainder of Mario Marietto's message, expressing gratitude]

You are asking for trouble if you install ubuntu packages on a debian
system. Do not do that.

Andrew Cater asked some helpful questions in his reply to your
original query:

 https://lists.debian.org/msgid-search/za9dq3bcfps7i...@einval.com

Namely:

On Mon, 13 Mar 2023 Andrew M.A. Cater wrote:

Which machine is this - maker?

Can you give more details of _which_ Debian installer you used -
i386 / amd64?

How recently did you install?

Did the machine fail to boot immediately?


--
Ce qui est important est rarement urgent
et ce qui est urgent est rarement important
-- Dwight David Eisenhower

Re: No /

[David Wright]

On Mon 13 Mar 2023 at 18:30:00 (+0100), Michael Lee wrote:
> Hello Tom, thanks for the reply. Good detective work. 
> 
> No, actually not; it's the SSD with the Debian on it. 

My detective work is limited to putting 1 and 1 together, your
posts in this case. Anyway, let's hazard a guess at what the
scenario might have been.

1 Debian 11 was running from sdc2 as root (ie /, not /root).
2 You removed a USB stick without unmounting it.
3 You typed reboot (or equivalent) intending to run another OS,
  but things didn't get that far.
4 Closing down Debian 11 was taking too long, maybe because of 2.
5 You powered off by holding down the power button.
6 You now get the symptoms described earlier.

So would this be roughly equivalent to how one should recover
a BTR filesystem's integrity after a power cut happens?

If this is so, it might be worth describing things in those terms,
and posting under a Subject like:

  Recovering a BTR filsystem after a power outage.

As for the last clause of your earlier post, I think you'd have
to give some idea of the disposition of your Debian system;
whether directories are spread over more than one partition,
and hence which settings would be affected were you to reinstall.

Cheers,
David.

Re: Debian Server

[Fred]

On 3/13/23 08:55, Dan Ritter wrote:

malpaso wrote:

*Hello!!!Please, I'm looking for guidance to set up a Server, it will not
be public, to host a flight simulator called Falcon BMS, about 12 people
flying online, the machine would be an I5 with 16 GB of RAM, Video Card GTX
1050 TI and a 480 GB SSD, please what would you guide me in this assembly,
I intend not to install Windows on the PC.I've been researching on the
internet and I got to Debian, please, I'm looking for guidance because I
don't understand this subject!Thanks in advance for any helpmalpaso*



From looking at the wiki, it appears that Falcon BMS requires

Falcon 4.0, which is only available on Windows.

If that is the case, this will not work.

-dsr-


Hi,

The flight simulator might run under wine which is available for Debian 
or the reasonably priced commercial version, Crossover.  The wine and 
crossover web sites probably still have a list of Windows programs that 
are known to run.


Best regards,
Fred

Re: real debian or true debian?

[davidson]

On Mon, 13 Mar 2023 cor...@free.fr wrote:

On 13/03/2023 10:12, Jeffrey Walton wrote:

On Sun, Mar 12, 2023 at 9:02 PM  wrote:


When such a debian (the digital product) is authentic, should we say it
"real debian" or "true debian"?

I am not sure about this statement.


Fee FieFoeFum
I smell the Blood of a True Scots Man [1]


I am having trouble parsing what you are asking... What is the context?

Debian provides distribution media, and it has Debian packages and
installs a Debian system. If it is not a Debian system, then it is not
a Debian installer and does not have Debian packages.

I'm not sure what "true" and "authentic" have to do with things.

Maybe you are talking about the signature?



No. I meant, some people pre-installed some packages on debian and release 
it, which is declared as xxx-debian.


I am just not sure about the two words "true" and "real". which is suitable 
for description of the "official" debian?


In the context you offer, my opinion is that "true" and "real" are as
nearly synonymous as two distinct terms can be. ("Authentic" is their
close cousin.)

And their meaning is remarkably subjective:

  "Official Debian installation media do not contain non-free
  firmware."

  "But what about updated social contract #5, which officially permits
  this?" [2]

  "Ahem. {*Real*,*True*} Debian installation media do not contain
  non-free firmware."


The term "official" itself is more objectively verifiable, and so less
arbitrarily deniable.


NOTES

1. https://en.wikipedia.org/wiki/No_true_Scotsman

2. Debian Installer Bookworm Alpha 2 release
   https://lists.debian.org/debian-devel-announce/2023/02/msg5.html

--
Ce qui est important est rarement urgent
et ce qui est urgent est rarement important
-- Dwight David Eisenhower

Grub bug on Debian 11

[Mario Marietto]

Hello to every Debian user.

excuse me if previously I sent this message quoting the wrong user. It was
a mistake. I don't know where that message has gone. It will be lost in the
space. Anyway,I want to send it again in the correct format :

"I've just installed Debian 11 and I see that it is affected by the bug
explained here :

https://bugs.launchpad.net/oem-priority/+bug/1842320

I see that the bug has been fixed on Ubuntu. Do you confirm that,to fix
it,I just need to install the package
"grub-efi-amd64_2.06-2ubuntu14.1_amd64.deb" with the command "dpkg -i
grub-efi-amd64_2.06-2ubuntu14.1_amd64.deb" on Debian 11 or do I just need
to do something else ?

thanks"
-- 
Mario.

Re: No /

[Michael Lee]

Hello Tom, thanks for the reply. Good detective work. 

No, actually not; it's the SSD with the Debian on it. 

Michael

Am Mittwoch, dem 08.03.2023 um 12:45 + schrieb Tom Furie:

Re: No /

[Michael Lee]

I'd like to help my system find its root, and so be able to complete
the boot up.
Michael

Am Dienstag, dem 07.03.2023 um 11:45 -0500 schrieb Dan Ritter:
> Michael Lee wrote: 
> > Is it possible to reinstall the system and still retain the
> > settings,
> > logins, etc.? 
> 
> Not as such.
> 
> That said: what do you actually want to accomplish? There may be
> ways to do what you want with less effort.
> 
> -dsr-
> 

Re: real debian or true debian?

[Cindy Sue Causey]

On 3/13/23, Stefan Monnier  wrote:
>> No. I meant, some people pre-installed some packages on debian and
>> release
>> it, which is declared as xxx-debian.
>
> What does "it" refers to?
>
> "some packages" meaning "some Debian packages" or "some non-Debian
> packages"?
>
>> I am just not sure about the two words "true" and "real". which is
>> suitable
>> for description of the "official" debian?
>
> If you mean "a system whose packages are all taken directly from
> Debian", I might describe it as "unadulterated" or "vanilla".
> Or maybe you're thinking of https://wiki.debian.org/DebianPureBlends,
> like FreedomBox?


"Pure" has been referenced on lists a few times, too. I'm finding
"Pure Debian," "Debian Pure," and "Debian Pure Blends" still lurking
in my emails. The "Pure Blends" instance sounds like it might be the
ultimate fit here.. maybe.

Freedombox and Distro Watch: Good News for Debian Pure Blends; 2019.09.06
https://lists.debian.org/debian-publicity/2019/09/msg2.html

Cindy :)
-- 
Talking Rock, Pickens County, Georgia, USA
* runs with determination*

Re: Debian Installer: Specifying the preseed file device?

[Charles Curley]

On Mon, 13 Mar 2023 16:36:11 +
Brian  wrote:

> That still leaves the first problem. How do you fancy running
> everything from a USB stick?

Not really, but that might work. Thanks.

-- 
Does anybody read signatures any more?

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

Re: Debian Installer: Specifying the preseed file device?

[Brian]

On Mon 13 Mar 2023 at 10:18:37 -0600, Charles Curley wrote:

> On Mon, 13 Mar 2023 14:58:08 +
> Brian  wrote:
> 
> > It is what d-i sees the partition as that is important and you
> > do know in advance. That's problem 1. Problem 2 is that the hard
> > disk partitions are probably ext4. At the opening stage of d-i
> > I do not think ext4 drivers are available.
> 
> Both partitions are FAT.

That still leaves the first problem. How do you fancy running
everything from a USB stick?

-- 
Brian.

Re: Debian Installer: Specifying the preseed file device?

[Mario Marietto]

Hello to every Debian user.

I've just installed Debian 11 and I see that it is affected by the bug
explained here :

https://bugs.launchpad.net/oem-priority/+bug/1842320

I see that the bug has been fixed on Ubuntu. Do you confirm that,to fix
it,I just need to install the package
"grub-efi-amd64_2.06-2ubuntu14.1_amd64.deb" with the command "dpkg -i
grub-efi-amd64_2.06-2ubuntu14.1_amd64.deb" on Debian 11 or I just need to
do something else ? thanks.

On Mon, Mar 13, 2023 at 5:19 PM Charles Curley <
charlescur...@charlescurley.com> wrote:

> On Mon, 13 Mar 2023 14:58:08 +
> Brian  wrote:
>
> > It is what d-i sees the partition as that is important and you
> > do know in advance. That's problem 1. Problem 2 is that the hard
> > disk partitions are probably ext4. At the opening stage of d-i
> > I do not think ext4 drivers are available.
>
> Both partitions are FAT.
>
> --
> Does anybody read signatures any more?
>
> https://charlescurley.com
> https://charlescurley.com/blog/
>
>

-- 
Mario.

Re: Debian Installer: Specifying the preseed file device?

[Charles Curley]

On Mon, 13 Mar 2023 14:58:08 +
Brian  wrote:

> It is what d-i sees the partition as that is important and you
> do know in advance. That's problem 1. Problem 2 is that the hard
> disk partitions are probably ext4. At the opening stage of d-i
> I do not think ext4 drivers are available.

Both partitions are FAT.

-- 
Does anybody read signatures any more?

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

Re: Debian Server

[Dan Ritter]

malpaso wrote: 
> *Hello!!!Please, I'm looking for guidance to set up a Server, it will not
> be public, to host a flight simulator called Falcon BMS, about 12 people
> flying online, the machine would be an I5 with 16 GB of RAM, Video Card GTX
> 1050 TI and a 480 GB SSD, please what would you guide me in this assembly,
> I intend not to install Windows on the PC.I've been researching on the
> internet and I got to Debian, please, I'm looking for guidance because I
> don't understand this subject!Thanks in advance for any helpmalpaso*

>From looking at the wiki, it appears that Falcon BMS requires
Falcon 4.0, which is only available on Windows.

If that is the case, this will not work.

-dsr-

Re: [bullseye] r-cran-ggplot2 depends on missing libpq5 v13.8

[David Wright]

On Mon 13 Mar 2023 at 07:38:50 (+0100), Loris Bennett wrote:
> David Wright  writes:
> > On Fri 10 Mar 2023 at 10:10:48 (+0100), Loris Bennett wrote:
> >> 
> >> I am on bullseye and am trying to install the package r-cran-ggplot2.
> >> This fails with 
> >> 
> >>   E: Failed to fetch
> >>   
> >> http://deb.debian.org/debian/pool/main/p/postgresql-13/libpq5_13.8-0%2bdeb11u1_amd64.deb
> >>   404  Not Found [IP: 146.75.122.132 80] 
> >> 
> >> (full output below).
> >> 
> >> There seems to be a dependency on libpq5 version 13.8 whereas the
> >> version available for bullseye is 13.9.
> >> 
> >> Any ideas how to solve this?
> >
> > Try:
> >
> > # apt-get update
> >
> > first.
> 
> I had already done this.  It does not solve the problem.

OK, forget all the r-cran stuff for the moment.
The current version of libpq5 is:

  $ dpkg -l | grep libpq5
  ii  libpq5:amd64  13.9-0+deb11u1  amd64  PostgreSQL C client library
  $ 

and you don't have libpq5 installed, so what do you get from this?

  # apt-get install libpq5

If that fails, I think we need to see your /etc/apt/sources.list
and anything in /etc/apt/sources.list.d/*

Cheers,
David.

Re: Debian Installer: Specifying the preseed file device?

[Brian]

On Mon 13 Mar 2023 at 08:01:51 -0600, Charles Curley wrote:

> On Mon, 13 Mar 2023 08:19:26 +0100
>  wrote:
> 
> > On Sun, Mar 12, 2023 at 04:08:28PM -0600, Charles Curley wrote:
> > > I can specify the path to the preseed file when booting Debian
> > > Installer (d-i). Is there any way to tell it that the preseed file
> > > is on device X, say /dev/sdb1?  
> > 
> > You mean: the file is as raw data on the device? Or whithin a file
> > system there?
> 
> I mean within a file system.
> 
> I specify what I want by entering the following at the boot prompt:
> 
> expert auto file=/media/preseed.cfg
> 
> Which tells d-i I want to use a specific file within a specific
> directory. So far so good.
> 
> That directory is the root of /dev/sdb1. Unfortunately, d-i finds a
> partition at /dev/sdaX, mounts that, and (rightly) reports no preseed
> file. Oops.
> 
> I'd like either
> 
> a) to specify which partition the preseed file is on (/dev/sdb1 in this
> case), or

It is what d-i sees the partition as that is important and you
do know in advance. That's problem 1. Problem 2 is that the hard
disk partitions are probably ext4. At the opening stage of d-i
I do not think ext4 drivers are available.

The awkward techniwue appears to be indicated.
 
> b) have d-i sample partitions until it finds a file of that name in the
> root directory of a partition.

I do not think thta would be easy to do.

-- 
Brian.

Re: Falcon BMS

[Tom Furie]

On Mon, Mar 13, 2023 at 10:59:14AM -0300, malpaso wrote:
> *Hello!!!Please, I'm looking for guidance to set up a Server, it will not
> be public, to host a flight simulator called Falcon BMS, about 12 people
> flying online, the machine would be an I5 with 16 GB of RAM, Video Card GTX
> 1050 TI and a 480 GB SSD, please what would you guide me in this assembly,
> I intend not to install Windows on the PC.I've been researching on the
> internet and I got to Debian, please, I'm looking for guidance because I
> don't understand this subject!Thanks in advance for any helpmalpaso*

To the best of my knowledge, and having checked the website in case anything
had changed recently, Falcon BMS only runs on Windows.

Cheers,
Tom

-- 
For reservations, call your travel agent.


signature.asc
Description: PGP signature

Debian Server

[malpaso]

*Hello!!!Please, I'm looking for guidance to set up a Server, it will not
be public, to host a flight simulator called Falcon BMS, about 12 people
flying online, the machine would be an I5 with 16 GB of RAM, Video Card GTX
1050 TI and a 480 GB SSD, please what would you guide me in this assembly,
I intend not to install Windows on the PC.I've been researching on the
internet and I got to Debian, please, I'm looking for guidance because I
don't understand this subject!Thanks in advance for any helpmalpaso*

Re: BIND: managed-keys-zone: Unable to fetch DNSKEY set '.': timed out

[Casey Deccio]

> On Mar 13, 2023, at 12:08 AM, local10  wrote:
> 
> I have  a local caching DNS server that was working fine for a long time but 
> today, all of a sudden, it stopped resolving queries.
> 
> More info: https://pastebin.com/iW5YeXgS
> 
> Any ideas? Thanks

Based on what I saw in the logs, your resolver is having trouble reaching the 
internet.  It shows problems with both the priming query (./NS) and the trust 
query (./DNSKEY).  Could you try running the following?

$ dig +norec @198.41.0.4 . NS
$ dig +norec @2001:503:ba3e::2:30 . NS
$ dig +norec @198.41.0.4 . DNSKEY
$ dig +norec @2001:503:ba3e::2:30 . DNSKEY

These manually send the same queries to the internet that your resolver is 
attempting.

Cheers,
Casey

Re: Debian Installer: Specifying the preseed file device?

[Charles Curley]

On Mon, 13 Mar 2023 08:19:26 +0100
 wrote:

> On Sun, Mar 12, 2023 at 04:08:28PM -0600, Charles Curley wrote:
> > I can specify the path to the preseed file when booting Debian
> > Installer (d-i). Is there any way to tell it that the preseed file
> > is on device X, say /dev/sdb1?  
> 
> You mean: the file is as raw data on the device? Or whithin a file
> system there?

I mean within a file system.

I specify what I want by entering the following at the boot prompt:

expert auto file=/media/preseed.cfg

Which tells d-i I want to use a specific file within a specific
directory. So far so good.

That directory is the root of /dev/sdb1. Unfortunately, d-i finds a
partition at /dev/sdaX, mounts that, and (rightly) reports no preseed
file. Oops.

I'd like either

a) to specify which partition the preseed file is on (/dev/sdb1 in this
case), or

b) have d-i sample partitions until it finds a file of that name in the
root directory of a partition.

-- 
Does anybody read signatures any more?

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


pgp5IQUoVaaRN.pgp
Description: OpenPGP digital signature

Re: BIND: managed-keys-zone: Unable to fetch DNSKEY set '.': timed out

[Reco]

On Mon, Mar 13, 2023 at 12:29:44PM +0100, local10 wrote:
> Mar 13, 2023, 10:57 by recovery...@enotuniq.net:
> 
> > And now to the serious stuff.
> >
> > First things first, the log.
> >
> > Mar 13 05:03:18 tst named[52836]: 13-Mar-2023 05:03:18.963 queries: info: 
> > client @0x7f7812816d68 127.0.0.1#38800 (www.yahoo.com 
> > ): query:
> > www.yahoo.com  IN A +E(0)K (127.0.0.1)
> > Mar 13 05:03:21 tst named[52836]: 13-Mar-2023 05:03:21.631 dnssec: warning: 
> > managed-keys-zone: Unable to fetch DNSKEY set '.': timed out
> >
> > The keyword here is not "managed-keys-zone", it's "dnssec".
> >
> > Second, to put it bluntly, if you force bind9 to do DNSSEC validation
> > (which is enabled by default), bind9 won't be able to lookup anything
> > unless it is trusting root DNSSEC key. Like, for your own security and
> > stuff :)
> >
> > Third, as every DNSSEC key, root zone keys have their expiration.
> > Meaning, you did not have to change anything to break your setup, every
> > time you deal with DNSSEC you're dealing with a ticking bomb anyway.
> >
> > Fourth, Debian packaging helpfully forces bind9 to depend on dns-root-data,
> > which should provide a current DNSSEC root key (KSK to be precise), but
> > bind9 could also take said key from /etc/bind/bind.keys.
> >
> >
> > In conclusion:
> >
> > 1) Check the contents of your /etc/bind/bind.keys, update if needed.
> > 2) Check the version of your dns-root-data, versions above and including
> > 2021011101 (aka ksk id 20326) are good.
> > 3) Set "dnssec-validation no;" at named.conf.options as a last resort.
> > 4) If you intend to troubleshoot DNS queries then consider installing
> > tcpdump. The thing helps.
>
> 
> Very interesting, thanks. in the "bind.keys" I have only one entry:
> 
> trust-anchors {
>     # This key (20326) was published in the root zone in 2017.
>     . initial-key 257 3 8 "";
> };

Looks correct, assuming that the contents of the key start with AwEAAaz
and end with V74bU=.


> But in "/etc/bind/named.conf.options" I have "dnssec-validation
> auto;", which, as I understand it should force bind to use the
> built-in root key, no?

Not exactly. "dnssec-validation auto;" should point BIND at
/etc/bind/bind.keys. And bind.keys should be created (or updated) by
debconf.
At least debconf did it for me back in 2021 during buster->bullseye
upgrade.


> Anyhow, how would I know if an update of /etc/bind/bind.keys is needed (it's 
> not obvious just by looking at the key)

Obviously you cannot know that ;)
Luckily "Root KSK Rollovers", as they call it, are rare. Last one was in
2018, and the key (aka ksk id 20326) in question was released in 2017.

> and, if so, how do I update it?

Look at /usr/share/dns/root.key. Compare its contents with
/etc/bind/bind.keys. Replace the latter if needed.

"dpkg-reconfigure -plow bind9" is probably more preferred way of doing
it.

Reco

Re: Debian docker image for development

[Dan Ritter]

p...@ymail.ne.jp wrote: 
> Hello,
> 
> Do you have a reference for the image of Debian devbox?
> Which would have the most modern development tools included, such as
> C/java/python/golang/node etc.
> I just don't want to re-make the wheels if there was already one.

There are too many different development tools to make a
reasonably sized universal image. Most people don't want all of
the tools at once.

https://hub.docker.com/_/debian and
https://cloud.debian.org/images/cloud/ might be useful to you.

The meta-package build-essential will be useful.

For Go and nodejs, Debian is a poor choice if you want the most
recent versions: they move too fast to be supportable in Stable.

I recommend that you install the majority of your systems from
Debian and then put specialized tools (that you care about and
are willing to monitor for bugs) in /opt.

-dsr-

Re: BIND: managed-keys-zone: Unable to fetch DNSKEY set '.': timed out

[Michel Verdier]

Le 13 mars 2023 local a écrit :

> Sure, I could have used some public DNS server and I may have to do that if I 
> can't get this issue resolved. Still, I'd like to understand why BIND 
> suddenly stopped working[1] for me and how to fix it.
>
> Regards,
>
> 1. It was working fine yesterday and I haven't done any config changes since.

Did you check memory and disk space as suggested by jeremy ?

Re: BIND: managed-keys-zone: Unable to fetch DNSKEY set '.': timed out

[local10]

Mar 13, 2023, 11:24 by g...@wooledge.org:

> For the record:
>
> unicorn:~$ sudo ss -ntlp | grep :53
> [sudo] password for greg: 
> LISTEN 0  20   0.0.0.0:53 0.0.0.0:*
> users:(("dnscache",pid=664,fd=4))
>
> In general, ss replaces netstat for this kind of query.  I don't know
> all the options, so you may need to read the manual if this isn't
> enough.
>

I see, thanks. The following is what I have:

# ss -ntlp | grep :53
LISTEN 0  10 127.0.0.1:53    0.0.0.0:*    
users:(("named",pid=6233,fd=19))
LISTEN 0  10 127.0.0.1:53    0.0.0.0:*    
users:(("named",pid=6233,fd=20))
LISTEN 0  10   xxx.xxx.xxx.xxx:53    0.0.0.0:*    
users:(("named",pid=6233,fd=25))
LISTEN 0  10   xxx.xxx.xxx.xxx:53    0.0.0.0:*    
users:(("named",pid=6233,fd=26))

Regards,

Re: BIND: managed-keys-zone: Unable to fetch DNSKEY set '.': timed out

[local10]

Mar 13, 2023, 10:57 by recovery...@enotuniq.net:

> And now to the serious stuff.
>
> First things first, the log.
>
> Mar 13 05:03:18 tst named[52836]: 13-Mar-2023 05:03:18.963 queries: info: 
> client @0x7f7812816d68 127.0.0.1#38800 (www.yahoo.com 
> ): query:
> www.yahoo.com  IN A +E(0)K (127.0.0.1)
> Mar 13 05:03:21 tst named[52836]: 13-Mar-2023 05:03:21.631 dnssec: warning: 
> managed-keys-zone: Unable to fetch DNSKEY set '.': timed out
>
> The keyword here is not "managed-keys-zone", it's "dnssec".
>
> Second, to put it bluntly, if you force bind9 to do DNSSEC validation
> (which is enabled by default), bind9 won't be able to lookup anything
> unless it is trusting root DNSSEC key. Like, for your own security and
> stuff :)
>
> Third, as every DNSSEC key, root zone keys have their expiration.
> Meaning, you did not have to change anything to break your setup, every
> time you deal with DNSSEC you're dealing with a ticking bomb anyway.
>
> Fourth, Debian packaging helpfully forces bind9 to depend on dns-root-data,
> which should provide a current DNSSEC root key (KSK to be precise), but
> bind9 could also take said key from /etc/bind/bind.keys.
>
>
> In conclusion:
>
> 1) Check the contents of your /etc/bind/bind.keys, update if needed.
> 2) Check the version of your dns-root-data, versions above and including
> 2021011101 (aka ksk id 20326) are good.
> 3) Set "dnssec-validation no;" at named.conf.options as a last resort.
> 4) If you intend to troubleshoot DNS queries then consider installing
> tcpdump. The thing helps.
>
> Reco
>

Very interesting, thanks. in the "bind.keys" I have only one entry:

trust-anchors {
    # This key (20326) was published in the root zone in 2017.
    . initial-key 257 3 8 "";
};

But in "/etc/bind/named.conf.options" I have "dnssec-validation auto;", which, 
as I understand it should force bind to use the built-in root key, no?

Anyhow, how would I know if an update of /etc/bind/bind.keys is needed (it's 
not obvious just by looking at the key) and, if so, how do I update it?

Regards,

Re: BIND: managed-keys-zone: Unable to fetch DNSKEY set '.': timed out

[Greg Wooledge]

On Mon, Mar 13, 2023 at 09:19:41AM +0100, local10 wrote:
> Mar 13, 2023, 07:25 by jer...@ardley.org:
> 
> > Try
> >
> > netstat -tulpnW | grep 53
> >
> > and see what's listening
> >
> 
> Bind seems to be listening on 127.0.0.1 port 53.
> 
> I don't have netstat installed and can't easily install it as aptitude can't 
> resolve Debian server's name to an IP, so the following is what I tried:

For the record:

unicorn:~$ sudo ss -ntlp | grep :53
[sudo] password for greg: 
LISTEN 0  20   0.0.0.0:53 0.0.0.0:*
users:(("dnscache",pid=664,fd=4))

In general, ss replaces netstat for this kind of query.  I don't know
all the options, so you may need to read the manual if this isn't
enough.

Re: BIND: managed-keys-zone: Unable to fetch DNSKEY set '.': timed out

[Reco]

Hi.

On Mon, Mar 13, 2023 at 10:57:48AM +0100, local10 wrote:
> Mar 13, 2023, 09:32 by jer...@ardley.org:
> 
> > My next best option is simply to remove your bind caching server (it sounds 
> > like it's not really necessary in your application)
> >
> > Backup /etc/bind and /var/cache/bind
> > then
> > systemctl remove bind9
> > systemctl purge bind9

LOL.

> > And then edit /etc/resolv.conf to
> >
> > nameserver 8.8.8.8
> > nameserver 8.8.4.4

And redirect all your DNS queries to Google.
I mean, people, if you suggest using a public DNS you could at least
consider suggesting a privacy-respecting one, like 9.9.9.9.


> Sure, I could have used some public DNS server and I may have to do that if I 
> can't get this issue resolved. Still, I'd like to understand why BIND 
> suddenly stopped working[1] for me and how to fix it.

And now to the serious stuff.

First things first, the log.

Mar 13 05:03:18 tst named[52836]: 13-Mar-2023 05:03:18.963 queries: info: 
client @0x7f7812816d68 127.0.0.1#38800 (www.yahoo.com ): 
query:
www.yahoo.com  IN A +E(0)K (127.0.0.1)
Mar 13 05:03:21 tst named[52836]: 13-Mar-2023 05:03:21.631 dnssec: warning: 
managed-keys-zone: Unable to fetch DNSKEY set '.': timed out

The keyword here is not "managed-keys-zone", it's "dnssec".

Second, to put it bluntly, if you force bind9 to do DNSSEC validation
(which is enabled by default), bind9 won't be able to lookup anything
unless it is trusting root DNSSEC key. Like, for your own security and
stuff :)

Third, as every DNSSEC key, root zone keys have their expiration.
Meaning, you did not have to change anything to break your setup, every
time you deal with DNSSEC you're dealing with a ticking bomb anyway.

Fourth, Debian packaging helpfully forces bind9 to depend on dns-root-data,
which should provide a current DNSSEC root key (KSK to be precise), but
bind9 could also take said key from /etc/bind/bind.keys.


In conclusion:

1) Check the contents of your /etc/bind/bind.keys, update if needed.
2) Check the version of your dns-root-data, versions above and including
2021011101 (aka ksk id 20326) are good.
3) Set "dnssec-validation no;" at named.conf.options as a last resort.
4) If you intend to troubleshoot DNS queries then consider installing
tcpdump. The thing helps.

Reco

Re: BIND: managed-keys-zone: Unable to fetch DNSKEY set '.': timed out

[local10]

Mar 13, 2023, 09:32 by jer...@ardley.org:

> My next best option is simply to remove your bind caching server (it sounds 
> like it's not really necessary in your application)
>
> Backup /etc/bind and /var/cache/bind
>
> then
>
> systemctl remove bind9
>
> systemctl purge bind9
>
> And then edit /etc/resolv.conf to
>
> nameserver 8.8.8.8
> nameserver 8.8.4.4
>
> and with luck everything will work O.K.
>
> You can do variants on that to use your ISP DNS servers instead
> ...
>


Sure, I could have used some public DNS server and I may have to do that if I 
can't get this issue resolved. Still, I'd like to understand why BIND suddenly 
stopped working[1] for me and how to fix it.

Regards,


1. It was working fine yesterday and I haven't done any config changes since.

Re: BIND: managed-keys-zone: Unable to fetch DNSKEY set '.': timed out

[Jeremy Ardley]

On 13/3/23 17:12, local10 wrote:


"debug 1;" doesn't seem to be a valid option, couldn't start BIND with it.  Anyhow, the 
following is what I get when running "dig www.yahoo.com"

Mar 13 05:03:11 tst systemd[1]: Started named.service - BIND Domain Name Server.
Mar 13 05:03:11 tst named[52836]: 13-Mar-2023 05:03:11.639 general: notice: 
running
Mar 13 05:03:18 tst named[52836]: 13-Mar-2023 05:03:18.963 queries: info: client 
@0x7f7812816d68 127.0.0.1#38800 (www.yahoo.com ): query: 
www.yahoo.com  IN A +E(0)K (127.0.0.1)
Mar 13 05:03:21 tst named[52836]: 13-Mar-2023 05:03:21.631 dnssec: warning: 
managed-keys-zone: Unable to fetch DNSKEY set '.': timed out
Mar 13 05:03:21 tst named[52836]: 13-Mar-2023 05:03:21.711 resolver: info: 
resolver priming query complete: timed out
Mar 13 05:03:23 tst named[52836]: 13-Mar-2023 05:03:23.966 queries: info: client 
@0x7f7812817b68 127.0.0.1#51554 (www.yahoo.com ): query: 
www.yahoo.com  IN A +E(0)K (127.0.0.1)
Mar 13 05:03:28 tst named[52836]: 13-Mar-2023 05:03:28.970 queries: info: client 
@0x7f78c9eb1168 127.0.0.1#42404 (www.yahoo.com ): query: 
www.yahoo.com  IN A +E(0)K (127.0.0.1)
Mar 13 05:03:30 tst named[52836]: 13-Mar-2023 05:03:30.970 resolver: info: shut down 
hung fetch while resolving 'www.yahoo.com/A '
Mar 13 05:03:30 tst named[52836]: 13-Mar-2023 05:03:30.970 query-errors: info: client 
@0x7f78c9eb1168 127.0.0.1#42404 (www.yahoo.com ): query failed 
(operation canceled) for www.yahoo.com/IN/A  at 
query.c:7775
Mar 13 05:03:30 tst named[52836]: 13-Mar-2023 05:03:30.970 query-errors: info: client 
@0x7f7812816d68 127.0.0.1#38800 (www.yahoo.com ): query failed 
(operation canceled) for www.yahoo.com/IN/A  at 
query.c:7775
Mar 13 05:03:30 tst named[52836]: 13-Mar-2023 05:03:30.970 query-errors: info: client 
@0x7f7812817b68 127.0.0.1#51554 (www.yahoo.com ): query failed 
(operation canceled) for www.yahoo.com/IN/A  at 
query.c:7775
Mar 13 05:03:38 tst named[52836]: 13-Mar-2023 05:03:38.966 resolver: info: 
resolver priming query complete: timed out

My next best option is simply to remove your bind caching server (it 
sounds like it's not really necessary in your application)


Backup /etc/bind and /var/cache/bind

then

systemctl remove bind9

systemctl purge bind9

And then edit /etc/resolv.conf to

nameserver 8.8.8.8
nameserver 8.8.4.4

and with luck everything will work O.K.

You can do variants on that to use your ISP DNS servers instead

You have to be careful in systemd about network processes overwriting 
/etc/resolv.conf. e.g. if you get a DHCP address, or if your system is 
somehow configured to use systemd-resolved which I know to have problems.


Actually before your start anything do

systemctl status systemd-resolved

and if it's not installed things should be fine.

You may get

systemctl status systemd-resolved
● systemd-resolved.service - Network Name Resolution
 Loaded: loaded (/lib/systemd/system/systemd-resolved.service; 
disabled; vendor preset: enabled)

 Active: inactive (dead)
   Docs: man:systemd-resolved.service(8)
 man:org.freedesktop.resolve1(5)
https://www.freedesktop.org/wiki/Software/systemd/writing-network-configuration-managers
https://www.freedesktop.org/wiki/Software/systemd/writing-resolver-clients

which is fine also.

In any case research on its configuration with

man systemd-resolved

I recall it uses a local address 127.0.0.53 to receive DNS queries

--
Jeremy
(Lists)

Re: BIND: managed-keys-zone: Unable to fetch DNSKEY set '.': timed out

[local10]

Mar 13, 2023, 08:31 by jer...@ardley.org:

> Sorry. Last message was garbled. Try this in /etc/bind/named.conf.options
>
> options {
>     // other configuration options ...
>     debug 1;
>     logging {
>     channel debug_log {
>     file "/var/log/bind9/debug.log" versions 3 size 5m;
>     severity dynamic;
>     print-time yes;
>     print-severity yes;
>     print-category yes;
>     };
>     category default {
>     debug_log;
>     };
>     };
> };
>
> also try setting /etc/resolv.conf to your ISP DNS servers - at least to get 
> software updates
>

"debug 1;" doesn't seem to be a valid option, couldn't start BIND with it.  
Anyhow, the following is what I get when running "dig www.yahoo.com"

Mar 13 05:03:11 tst systemd[1]: Started named.service - BIND Domain Name Server.
Mar 13 05:03:11 tst named[52836]: 13-Mar-2023 05:03:11.639 general: notice: 
running
Mar 13 05:03:18 tst named[52836]: 13-Mar-2023 05:03:18.963 queries: info: 
client @0x7f7812816d68 127.0.0.1#38800 (www.yahoo.com ): 
query: www.yahoo.com  IN A +E(0)K (127.0.0.1)
Mar 13 05:03:21 tst named[52836]: 13-Mar-2023 05:03:21.631 dnssec: warning: 
managed-keys-zone: Unable to fetch DNSKEY set '.': timed out
Mar 13 05:03:21 tst named[52836]: 13-Mar-2023 05:03:21.711 resolver: info: 
resolver priming query complete: timed out
Mar 13 05:03:23 tst named[52836]: 13-Mar-2023 05:03:23.966 queries: info: 
client @0x7f7812817b68 127.0.0.1#51554 (www.yahoo.com ): 
query: www.yahoo.com  IN A +E(0)K (127.0.0.1)
Mar 13 05:03:28 tst named[52836]: 13-Mar-2023 05:03:28.970 queries: info: 
client @0x7f78c9eb1168 127.0.0.1#42404 (www.yahoo.com ): 
query: www.yahoo.com  IN A +E(0)K (127.0.0.1)
Mar 13 05:03:30 tst named[52836]: 13-Mar-2023 05:03:30.970 resolver: info: shut 
down hung fetch while resolving 'www.yahoo.com/A '
Mar 13 05:03:30 tst named[52836]: 13-Mar-2023 05:03:30.970 query-errors: info: 
client @0x7f78c9eb1168 127.0.0.1#42404 (www.yahoo.com ): 
query failed (operation canceled) for www.yahoo.com/IN/A 
 at query.c:7775
Mar 13 05:03:30 tst named[52836]: 13-Mar-2023 05:03:30.970 query-errors: info: 
client @0x7f7812816d68 127.0.0.1#38800 (www.yahoo.com ): 
query failed (operation canceled) for www.yahoo.com/IN/A 
 at query.c:7775
Mar 13 05:03:30 tst named[52836]: 13-Mar-2023 05:03:30.970 query-errors: info: 
client @0x7f7812817b68 127.0.0.1#51554 (www.yahoo.com ): 
query failed (operation canceled) for www.yahoo.com/IN/A 
 at query.c:7775
Mar 13 05:03:38 tst named[52836]: 13-Mar-2023 05:03:38.966 resolver: info: 
resolver priming query complete: timed out

Regards,

Re: BIND: managed-keys-zone: Unable to fetch DNSKEY set '.': timed out

[Jeremy Ardley]

On 13/3/23 16:19, local10 wrote:

Mar 13, 2023, 07:25 by jer...@ardley.org:


Try

netstat -tulpnW | grep 53

and see what's listening


Bind seems to be listening on 127.0.0.1 port 53.

I don't have netstat installed and can't easily install it as aptitude can't 
resolve Debian server's name to an IP, so the following is what I tried:


# telnet -4 127.0.0.1 53
Trying 127.0.0.1...
Connected to 127.0.0.1.
Escape character is '^]'.
^]
telnet> quit
Connection closed.
#
#
# systemctl stop  named.service
#
#
# telnet -4 127.0.0.1 53
Trying 127.0.0.1...
telnet: Unable to connect to remote host: Connection refused
#
#
# systemctl restart  named.service
#
#
# telnet -4 127.0.0.1 53
Trying 127.0.0.1...
Connected to 127.0.0.1.
Escape character is '^]'.
^]
telnet> quit
Connection closed.
#


Sorry. Last message was garbled. Try this in /etc/bind/named.conf.options

options {
    // other configuration options ...
    debug 1;
    logging {
    channel debug_log {
    file "/var/log/bind9/debug.log" versions 3 size 5m;
    severity dynamic;
    print-time yes;
    print-severity yes;
    print-category yes;
    };
    category default {
    debug_log;
    };
    };
};

also try setting /etc/resolv.conf to your ISP DNS servers - at least to 
get software updates






--
Jeremy
(Lists)

Re: BIND: managed-keys-zone: Unable to fetch DNSKEY set '.': timed out

[Jeremy Ardley]

On 13/3/23 16:19, local10 wrote:


Bind seems to be listening on 127.0.0.1 port 53.
I don't have netstat installed and can't easily install it as aptitude can't 
resolve Debian server's name to an IP, so the following is what I tried:


# telnet -4 127.0.0.1 53
Trying 127.0.0.1...
Connected to 127.0.0.1.
Escape character is '^]'.
^]
telnet> quit
Connection closed.
#
#
# systemctl stop  named.service
#
#
# telnet -4 127.0.0.1 53
Trying 127.0.0.1...
telnet: Unable to connect to remote host: Connection refused
#
#
# systemctl restart  named.service
#
#
# telnet -4 127.0.0.1 53
Trying 127.0.0.1...
Connected to 127.0.0.1.
Escape character is '^]'.
^]
telnet> quit
Connection closed.
#



At this stage I'd suggest wireshark but that won't be an option. Perhaps 
tcpdump is available?


Another option might be to set up a forwarder such as 8.8.8.8 or 1.1.1.1.

You can also edit debug options into to /etc/bind/named.conf.options

|options { // other configuration options ... // Debug Options debug 1; 
logging { channel debug_log { file "/var/log/bind9/debug.log" versions 3 
size 5m; severity dynamic; print-time yes; print-severity yes; 
print-category yes; }; category default { debug_log; }; }; // End debug 
options }; |



--
Jeremy
(Lists)

Re: BIND: managed-keys-zone: Unable to fetch DNSKEY set '.': timed out

[local10]

Mar 13, 2023, 07:25 by jer...@ardley.org:

> Try
>
> netstat -tulpnW | grep 53
>
> and see what's listening
>

Bind seems to be listening on 127.0.0.1 port 53.

I don't have netstat installed and can't easily install it as aptitude can't 
resolve Debian server's name to an IP, so the following is what I tried:


# telnet -4 127.0.0.1 53
Trying 127.0.0.1...
Connected to 127.0.0.1.
Escape character is '^]'.
^]
telnet> quit
Connection closed.
#
#
# systemctl stop  named.service
#
#
# telnet -4 127.0.0.1 53
Trying 127.0.0.1...
telnet: Unable to connect to remote host: Connection refused
#
#
# systemctl restart  named.service
#
#
# telnet -4 127.0.0.1 53
Trying 127.0.0.1...
Connected to 127.0.0.1.
Escape character is '^]'.
^]
telnet> quit
Connection closed.
#


Regards,

Re: real debian or true debian?

[Jude DaShiell]

Likely debuan came up for consideration in this context.  That if it is
the case can be handled easily.  Rather than real or true original would
better fit in this case since debuan is a fork of debian.


Jude 
"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)

.

On Mon, 13 Mar 2023, cor...@free.fr wrote:

> On 13/03/2023 10:12, Jeffrey Walton wrote:
> > On Sun, Mar 12, 2023 at 9:02?PM  wrote:
> >>
> >> When such a debian (the digital product) is authentic, should we say it
> >> "real debian" or "true debian"?
> >>
> >> I am not sure about this statement.
> >
> > I am having trouble parsing what you are asking... What is the context?
> >
> > Debian provides distribution media, and it has Debian packages and
> > installs a Debian system. If it is not a Debian system, then it is not
> > a Debian installer and does not have Debian packages.
> >
> > I'm not sure what "true" and "authentic" have to do with things.
> >
> > Maybe you are talking about the signature?
> >
>
> No. I meant, some people pre-installed some packages on debian and release it,
> which is declared as xxx-debian.
>
> I am just not sure about the two words "true" and "real". which is suitable
> for description of the "official" debian?
>
> Thanks
> Corey
>
>

Debian docker image for development

[p...@ymail.ne.jp]

Hello,

Do you have a reference for the image of Debian devbox?
Which would have the most modern development tools included, such as 
C/java/python/golang/node etc.

I just don't want to re-make the wheels if there was already one.

Thanks & regards,
Yong

Re: BIND: managed-keys-zone: Unable to fetch DNSKEY set '.': timed out

[Jeremy Ardley]

On 13/3/23 14:34, local10 wrote:

Mar 13, 2023, 06:19 by jer...@ardley.org:


The contents of /etc/resolv.conf are always of interest.



There's really not much there:

# cat /etc/resolv.conf
nameserver 127.0.0.1




That and /etc/nsswitch.conf a/etc/hosts


# cat /etc/nsswitch.conf
# /etc/nsswitch.conf
#
# Example configuration of GNU Name Service Switch functionality.
# If you have the `glibc-doc-reference' and `info' packages installed, try:
# `info libc "Name Service Switch"' for information about this file.

passwd: files
group:  files
shadow: files
gshadow:    files

hosts:  files mdns4_minimal [NOTFOUND=return] dns
networks:   files

protocols:  db files
services:   db files
ethers: db files
rpc:    db files

netgroup:   nis


# cat /etc/hosts

127.0.0.1   localhost




You should also check if there are any new firewall issues, and that you 
haven't run out of space somewhere.

Finally, you may have forwarder(s) in your bind. It's best to check if that is 
working



No changes were made to the firewall and there are no firewall issues I'm aware of. The 
forwarder's section in the "/etc/bind/named.conf.options" is commented out so 
there are no forwarders:

    // forwarders {
     //  0.0.0.0;
     // };


# aptitude show bind9
Package: bind9
Version: 1:9.18.12-1


Try

netstat -tulpnW | grep 53

and see what's listening

--
Jeremy
(Lists)

Re: Debian Installer: Specifying the preseed file device?

[tomas]

On Sun, Mar 12, 2023 at 04:08:28PM -0600, Charles Curley wrote:
> I can specify the path to the preseed file when booting Debian Installer
> (d-i). Is there any way to tell it that the preseed file is on device
> X, say /dev/sdb1?

You mean: the file is as raw data on the device? Or whithin a file
system there?

> Does anybody read signatures any more?

Yes, sometimes.

Cheers
-- 
t


signature.asc
Description: PGP signature

Re: home server for email box

[tomas]

On Mon, Mar 13, 2023 at 08:56:04AM +0800, p...@ymail.ne.jp wrote:
> 
> 
> Jeremy Ardley wrote:
> >   * TLS connection with certificate that can't be verified
> 
> postfix can work with this way. MTA to MTA doesn't require a valid
> certificate (Said by postfix's author on the list). But HTTPs does require.

When it doesn't, it's called HTTP ;-)

Cheers
-- 
t


signature.asc
Description: PGP signature

Re: home server for email box

[tomas]

On Mon, Mar 13, 2023 at 03:35:20AM +0100, Vincent Lefevre wrote:
> On 2023-03-12 22:30:50 -0400, Jeffrey Walton wrote:
> > Security on a channel (like HTTPS) usually makes it tougher to inspect
> > traffic. Or at least it makes it tougher in HTTPS. In fact, spam
> > filters are mostly useless for messages encrypted with a tool like GPG
> > or GnuPG.
> 
> Are there spammers who send encrypted messages???
> This seems counterproductive.

It seems doable, but somewhat awkward. For a spammer to send me an
encrypted message, they would have to fetch my public key. This
would have to happen in an automated way (on spam, every millionth
of a cent counts). Doable, but given the population sice (and
arguably, type) I don't think it would add up.

Of course, TLS is a whole different kettle of fish. On the one hand,
it's just the /transport/ which is secured (so the systems [1] on
both sides know the plaintext and can run whatever Bayes they like
on it. On the other hand, spammers can just get a LetsEncrypt
cert for only the setup cost -- so just having a "valid certificate"
wouldn't count very much towards the trust chain. Having a valid
certificate tied to the DNS would count a bit more (yes, someone
might lose control of their DNS, but those events are statistically
more sparse).

[1] I consider browsers more like MTAs as whole systems. They are
   operating systems in their own right, with knowledge about your
   hardware, running other people's code on your box and a small
   fractal of window managers, GUI toolkits, virtual machine Rube
   Goldbergisms and all that. For better or worse. Worse, if you
   ask me.

Cheers
-- 
t


signature.asc
Description: PGP signature