|
Участник с: 02 января 2023
|
Ой вы гой яси да красноглазики, повелители хэшей, эпигоны мистерий компиляции, братья по разуму.
Моя электронная радистка Кэт в серьёзном загуле - не работает удалённый импорт ключей. При обновлении системы:
:: PGP keys need importing:
-> 8657ABB260F056B1E5190839D9C4D26D0E604491, required by: openssl-1.0
...
:: Import? [Y/n]
:: Importing keys with gpg...
gpg: keyserver receive failed: Try again later
Когда пытаешься делать ручками - матюги приобретают более осмысленный вид
>> dirmngr </dev/null
dirmngr[11091.0]: permanently loaded certificates: 140
dirmngr[11091.0]: runtime cached certificates: 0
dirmngr[11091.0]: trusted certificates: 140 (140,0,0,0)
# Home: /home/varnava/.gnupg
# Config: /home/varnava/.gnupg/dirmngr.conf
OK Dirmngr 2.2.40 at your service
( ~ ) >> gpg --debug-level 10 --recv-keys 8657ABB260F056B1E5190839D9C4D26D0E604491
...
gpg: DBG: chan_3 -> KS_GET -- 0x8657ABB260F056B1E5190839D9C4D26D0E604491
gpg: DBG: chan_3 <- ERR 167772472 Try again later <Dirmngr>
gpg: keyserver receive failed: Try again later
gpg: DBG: chan_3 -> BYE
gpg: DBG: [not enabled in the source] stop
gpg: keydb: handles=0 locks=0 parse=0 get=0
gpg: build=0 update=0 insert=0 delete=0
gpg: reset=0 found=0 not=0 cache=0 not=0
gpg: kid_not_found_cache: count=0 peak=0 flushes=0
gpg: sig_cache: total=0 cached=0 good=0 bad=0
gpg: random usage: poolsize=600 mixed=0 polls=0/0 added=0/0
outmix=0 getlvl1=0/0 getlvl2=0/0
gpg: rndjent stat: collector=0x0000000000000000 calls=0 bytes=0
gpg: secmem usage: 0/32768 bytes in 0 blocks
Чего я только не делал - скрежитал зубами, ходил из угла в угол, пнул соседского кота, а также:
1. Переустанавливал GNUPG со сносом домашней директории с перетряхиванием настроек, перебором серверов ключей и прочим шаманизмом и шпионской алхимистикой.
2. Стучал молотком и, даже, бил кувалдой по резолверу - менял его настройки, делал его статическим и создавал ссылку на файл заглушки по вики, изменял умолчательному резолверу с openresolv и пр.
3. Убил Била - делал sudo killall dirmngr, кричал на соседского кота, одержимо ковырял в настройках dirmngr - щас даже не вспомню каких - лог его знает.
4. Матюгал pacman - менял уровни SigLevel, пытался полностью переустанавливать систему подписи ключей. Сбой начинает проявляться на этапе pacman-key --refresh-key - перестаёт находить сервера.
Вот это царство мрака и боли:
>> sudo pacman -Qii gnupg
Name : gnupg
Version : 2.2.40-1
Description : Complete and free implementation of the OpenPGP standard
Architecture : x86_64
URL : https://www.gnupg.org/
Licenses : BSD custom custom:CC0 GPL2 GPL3 LGPL3 LGPL2.1 MIT
Groups : None
Provides : None
Depends On : bzip2 libbz2.so=1.0-64 glibc gnutls libgcrypt libgpg-error libksba libassuan libassuan.so=0-64 npth libnpth.so=0-64 pinentry readline libreadline.so=8-64
sqlite zlib
Optional Deps : libldap: gpg2keys_ldap [installed]
libusb-compat: scdaemon [installed]
pcsclite: scdaemon [installed]
Required By : archstrike-keyring gpgme pacman
...
Backup Files :
(none)
>> cat /etc/pacman.d/gnupg/gpg.conf
no-greeting
no-permission-warning
lock-never
keyserver-options timeout=10
keyserver-options import-clean
keyserver-options no-self-sigs-only
# keyserver hkp://keyserver.kjsl.com:80
keyserver hkp://keyserver.ubuntu.com
>> cat ~/.gnupg/dirmngr.conf
standard-resolver
no-use-tor
nameserver 1.1.1.1
disable-ipv6
>> ps -p `pgrep dirmngr | paste -sd,` -o pid=,ppid=,comm=,args=
11018 532 dirmngr /usr/bin/dirmngr --supervised
>> systemctl --user list-units dirmngr* gpg*
UNIT LOAD ACTIVE SUB DESCRIPTION
dirmngr.service loaded active running GnuPG network certificate management daemon
dirmngr.socket loaded active running GnuPG network certificate management daemon
gpg-agent-browser.socket loaded active listening GnuPG cryptographic agent and passphrase cache (access for web browsers)
gpg-agent-extra.socket loaded active listening GnuPG cryptographic agent and passphrase cache (restricted)
gpg-agent-ssh.socket loaded active listening GnuPG cryptographic agent (ssh-agent emulation)
gpg-agent.socket loaded active listening GnuPG cryptographic agent and passphrase cache
...
Wifi повешан на iwd, в настройках которого разрешена встроенная настройка сети (опция EnableNetworkConfiguration=true):
cat /etc/iwd/main.conf
[General]
EnableNetworkConfiguration=true
[Network]
NameResolvingService=systemd
# NameResolvingService=resolvconf
EnableIPv6=false
>> 0.status iwd
● iwd.service - Wireless service
Loaded: loaded (/usr/lib/systemd/system/iwd.service; enabled; preset: disabled)
Active: active (running) since Mon 2023-01-02 01:20:49 +05; 12h ago
Docs: man:iwd(8)
man:iwd.config(5)
man:iwd.network(5)
man:iwd.ap(5)
Main PID: 420 (iwd)
Tasks: 1 (limit: 6951)
Memory: 2.5M
CPU: 140ms
CGroup: /system.slice/iwd.service
└─420 /usr/lib/iwd/iwd
Jan 02 01:20:51 pampas iwd[420]: [DHCPv4] l_dhcp_client_start:1219 Entering state: DHCP_STATE_SELECTING
Jan 02 01:20:53 pampas iwd[420]: [DHCPv4] dhcp_client_handle_offer:811 Entering state: DHCP_STATE_REQUESTING
Jan 02 01:20:53 pampas iwd[420]: [DHCPv4] dhcp_client_rx_message:915 Entering state: DHCP_STATE_BOUND
Jan 02 01:20:53 pampas iwd[420]: [DHCPv4] dhcp_client_rx_message:948 T1 expiring in 43199306 ms
Jan 02 12:08:06 pampas iwd[420]: Received Deauthentication event, reason: 3, from_ap: false
Jan 02 12:08:06 pampas iwd[420]: [DHCPv4] l_dhcp_client_stop:1264 Entering state: DHCP_STATE_INIT
Jan 02 12:08:07 pampas iwd[420]: [DHCPv4] l_dhcp_client_start:1219 Entering state: DHCP_STATE_SELECTING
Jan 02 12:08:09 pampas iwd[420]: [DHCPv4] dhcp_client_handle_offer:811 Entering state: DHCP_STATE_REQUESTING
Jan 02 12:08:09 pampas iwd[420]: [DHCPv4] dhcp_client_rx_message:915 Entering state: DHCP_STATE_BOUND
Jan 02 12:08:09 pampas iwd[420]: [DHCPv4] dhcp_client_rx_message:948 T1 expiring in 43199811 ms
В данный момент используется заглушка конфига резолвера
>> cat /etc/resolv.conf
# This is /run/systemd/resolve/stub-resolv.conf managed by man:systemd-resolved(8).
# Do not edit.
...
# See man:systemd-resolved.service(8) for details about the supported modes of
# operation for /etc/resolv.conf.
nameserver 127.0.0.53
options edns0 trust-ad
search .
>> systemd-resolve --status
Global
Protocols: +LLMNR +mDNS -DNSOverTLS DNSSEC=no/unsupported
resolv.conf mode: foreign
Fallback DNS Servers: 1.1.1.1#cloudflare-dns.com 9.9.9.9#dns.quad9.net 8.8.8.8#dns.google 2606:4700:4700::1111#cloudflare-dns.com 2620:fe::9#dns.quad9.net 2001:4860:4860::8888#dns.google
Link 2 (enp4s0)
Current Scopes: none
Protocols: -DefaultRoute +LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported
Link 4 (wlan0)
Current Scopes: DNS LLMNR/IPv4 LLMNR/IPv6
Protocols: +DefaultRoute +LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported
Current DNS Server: 192.168.0.1
DNS Servers: 192.168.0.1
В работе юнита резолвера есть проблемки:
>> 0.status systemd-resolved.service
● systemd-resolved.service - Network Name Resolution
Loaded: loaded (/usr/lib/systemd/system/systemd-resolved.service; enabled; preset: enabled)
Active: active (running) since Mon 2023-01-02 13:19:19 +05; 1min 46s ago
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
Main PID: 13505 (systemd-resolve)
Status: "Processing requests..."
Tasks: 1 (limit: 6951)
Memory: 2.7M
CPU: 80ms
CGroup: /system.slice/systemd-resolved.service
└─13505 /usr/lib/systemd/systemd-resolved
Jan 02 13:19:19 pampas systemd[1]: Starting Network Name Resolution...
Jan 02 13:19:19 pampas systemd-resolved[13505]: Positive Trust Anchors:
Jan 02 13:19:19 pampas systemd-resolved[13505]: . IN DS 20326 8 2 e06d44b80b8f1d39a95c0b0d7c65d08458e880409bbc683457104237c7f8ec8d
Jan 02 13:19:19 pampas systemd-resolved[13505]: Negative trust anchors: home.arpa 10.in-addr.arpa 16.172.in-addr.arpa 17.172.in-addr.arpa 18.172.in-addr.arpa 19.172.in-addr.arpa 20.172.in-ad>
Jan 02 13:19:19 pampas systemd-resolved[13505]: Using system hostname 'pampas'.
Jan 02 13:19:19 pampas systemd[1]: Started Network Name Resolution.
Jan 02 13:20:20 pampas systemd-resolved[13505]: Using degraded feature set UDP instead of UDP+EDNS0 for DNS server 192.168.0.1.
>> resolvectl query keyserver.ubuntu.com
keyserver.ubuntu.com: 162.213.33.9 -- link: wlan0
162.213.33.8 -- link: wlan0
-- Information acquired via protocol DNS in 295.7ms.
-- Data is authenticated: no; Data was acquired via local or encrypted transport: no
-- Data from: network
>> ping keyserver.ubuntu.com
PING keyserver.ubuntu.com (162.213.33.8) 56(84) bytes of data.
^C
--- keyserver.ubuntu.com ping statistics ---
9 packets transmitted, 0 received, 100% packet loss, time 8210ms
>> ping google.com
PING google.com (173.194.222.102) 56(84) bytes of data.
64 bytes from lo-in-f102.1e100.net (173.194.222.102): icmp_seq=1 ttl=59 time=73.2 ms
64 bytes from lo-in-f102.1e100.net (173.194.222.102): icmp_seq=2 ttl=59 time=71.3 ms
64 bytes from lo-in-f102.1e100.net (173.194.222.102): icmp_seq=3 ttl=59 time=85.9 ms
^C
--- google.com ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2003ms
rtt min/avg/max/mdev = 71.328/76.790/85.866/6.461 ms
Помогите малятки, а?
|
