gpg сбой при получении с сервера ключей

Хотя по http работает. Хост думаю норм
#
# /etc/hosts: static lookup table for host names
#

#<ip-address>	<hostname.domain.org>	<hostname>
127.0.0.1	localhost.localdomain	localhost R510.localdomain R510
::1		localhost.localdomain	localhost R510.localdomain R510

#127.0.0.1	R510.localdomain	R510
#::1	R510.localdomain	R510

# End of file
Ulin
Знаешь может сломан интернет наполовину.
С интернетом и без разницы нет.
Вряд ли сломан — просто не пускает на сервер, судя по логу вместо сообщения типа
gpg: DBG: chan_3 <- S SOURCE https://193.224.163.43:443
ты получаешь сообщение
gpg: DBG: chan_3 <- ERR 167805009 Нет такого файла или катал� <Dirmngr>

UPD … Опять тебя обманул, у меня все работает и из под root …..
Вчера был невнимателен — не смог получить ключ, видимо ошибся в команде — сейчас 2 раза проверил, все проходит нормально.
И подкорректировал выше свое сообщение
vasek
Вот моя концовка (она побольше, ключ находится, но меня с сервера выкинули виноват нажал Q - а не выкинуло )
не выкинуло, а вышел сам, через Q. Писал под впечатлением, что не смог получить ключ.
Ошибок накапливается у меня все больше и больше — пора мне завязывать.
Если что встречу толковое, отпишусь.
PS ... только сейчас обратил внимание на символ - - это что, глюк или что с кодировкой??? - а не может быть причина в этом?
PSS ... а выход вижу один - искать почему не пускает на сервер - можно опять потрейсить с фильтром network и смотреть вызовы connect, accept и др. + другие сетевые утилиты ...
Ошибки не исчезают с опытом - они просто умнеют
Уважаемые админы, чувствую, что я уже достал своей писаниной - все, на этом заканчиваю.
Ошибки не исчезают с опытом - они просто умнеют
Проблема не решена. С кодировками ок utf-8 работае.
Ulin
Проблема не решена.
Выход вижу один, рекомендую заняться анализом доступа на сервер ключей — посмотреть прохождение и чтение пакетов, используя нестандартные сетевые утилиты, например, самая простая и не требующая навыков работы - ngrep и самая сложная, требующая определенных знаний и навыков работы - wireshark. Плюс к этому, как уже писал, дополнительно к этим утилитам не забывать и о strace, в части анализа сетевых системных вызовов.
Мое мнение — нужно понять, что там на сервере ключей делается, грубо говоря, посмотреть, как идет обмен пакетами в обе стороны и чем это все заканчивается.
Ошибки не исчезают с опытом - они просто умнеют
Wireshark знаю. пользовался. Ок. спасибо буду пробовать.
Wireshark не показал никакого намека на внешнее соединение. Да и вообще были логи с локаль вайфая только. ngrep действительно очень прост и он тоже молчит.
Ulin
Wireshark не показал никакого намека на внешнее соединение. Да и вообще были логи с локаль вайфая только. ngrep действительно очень прост и он тоже молчит.
Тогда попробуй посмотреть, что выдает ngrep - а для этого запусти так:
Перед началом - закрыть приложения, проявляющие сетевую активность и # killall dirmngr
- запусти два терминала
- в 1-ом терминале
# ngrep > ~/ngrep.log
- перейти на 2-ой терминал и
$ gpg --debug 1024 --keyserver hkps://hkps.pool.sks-keyservers.net --search-keys B4322F04D67658D8
и после отработки/завершения, закрыть запущенные приложения в обоих терминалах - ну и смотри файл ~/ngrep.log …..
Ошибки не исчезают с опытом - они просто умнеют
В части ngrep — просто хотел, что бы ты посмотрел движение пакетов — на начальном уровне анализа с его помощью можно получить стартовую информацию ...
Без обид, что то потянуло на стариковские нравоучения ....
Если есть желание разбираться с пакетами и их прохождением, то рекомендую использовать самый лучший для этих целей инструмент (лучшего я еще не встречал) — язык не поворачивается назвать утилитой — это программа, точнее программный комплекс, scapy, который позволяет самому готовить пакеты и отправлять их, смотреть доходят ли они до адресата, вплоть до трассировки маршрута и многое другое (о чем не говорят, чему не учат в школе) …. но требует тщательного изучения.
UPD ... но это все анализ, а вот для выяснения причины (или хотя бы определения какого то причинного фактора) без strace не обойтись.
Ошибки не исчезают с опытом - они просто умнеют
Привет) я снова здеся. Снова решил разобратся...
Решение оказалось очень даже простым)
Пишем
ps aux | grep dirmngr
Получаем
root      5366  0.9  0.9 145236 23020 ?        Ss   20:37   0:00 dirmngr --daemon --homedir /etc/pacman.d/gnupg
root      5416  0.0  0.0  12880  2168 pts/4    S+   20:38   0:00 grep dirmngr
Пишем под рутом
dirmngr --daemon --homedir /etc/pacman.d/gnupg
Появляются интересные логи
dirmngr --daemon --homedir /etc/pacman.d/gnupg
dirmngr[5174]: NOTE: DirMngr is now a proper part of GnuPG.  The configuration and other directory names changed.  Please check that no other version of dirmngr is still installed.  To disable this warning, remove the directory '/etc/dirmngr'.
dirmngr[5174]: ошибка открытия '/etc/pacman.d/gnupg/dirmngr_ldapservers.conf': Нет такого файла или каталога
dirmngr[5150.0]: socket file has been removed - shutting down
DIRMNGR_INFO=/etc/pacman.d/gnupg/S.dirmngr:5175:1; export DIRMNGR_INFO;
[root@R510 denis]# dirmngr[5150.0]: dirmngr (GnuPG) 2.1.21 stopped
dirmngr[5175.0]:       постоянно загруженных сертификатов: 158
dirmngr[5175.0]: сертификатов в буфере времени исполнения: 0
dirmngr[5175.0]:                 достоверных сертификатов: 158 (157,0,0,1)
Послушаляс варнинга, Удалил /etc/dirmngr, и заодно сделал touch /etc/pacman.d/gnupg/dirmngr_ldapservers.conf
Ничего не изменилось, пробую refresh key, и тут в открытом dirmng появляются новые логищя

dirmngr[5199.5]: failed to load '/etc/resolv.conf': Нет такого файла или каталога
dirmngr[5199.5]: number of system provided CAs: 172
dirmngr[5199.5]: failed to load '/etc/resolv.conf': Нет такого файла или каталога
dirmngr[5199.5]: resolving 'pool.sks-keyservers.net' failed: Нет такого файла или каталога
dirmngr[5199.5]: can't connect to 'pool.sks-keyservers.net': host not found
dirmngr[5199.5]: ошибка соединения с 'http://pool.sks-keyservers.net:11371': Нет такого файла или каталога
dirmngr[5199.5]: failed to load '/etc/resolv.conf': Нет такого файла или каталога
dirmngr[5199.5]: resolving 'pool.sks-keyservers.net' failed: Нет такого файла или каталога
dirmngr[5199.5]: can't connect to 'pool.sks-keyservers.net': host not found
dirmngr[5199.5]: ошибка соединения с 'http://pool.sks-keyservers.net:11371': Нет такого файла или каталога
dirmngr[5199.5]: failed to load '/etc/resolv.conf': Нет такого файла или каталога
dirmngr[5199.5]: resolving 'pool.sks-keyservers.net' failed: Нет такого файла или каталога
dirmngr[5199.5]: can't connect to 'pool.sks-keyservers.net': host not found
dirmngr[5199.5]: ошибка соединения с 'http://pool.sks-keyservers.net:11371': Нет такого файла или каталога
dirmngr[5199.5]: failed to load '/etc/resolv.conf': Нет такого файла или каталога
dirmngr[5199.5]: resolving 'pool.sks-keyservers.net' failed: Нет такого файла или каталога
dirmngr[5199.5]: can't connect to 'pool.sks-keyservers.net': host not found

Все вродебы нормально, но тут смутило меня dirmngr[5199.5]: failed to load '/etc/resolv.conf': Нет такого файла или каталога
Тоесть он зачем-то использует ети dns..

ls -sl /etc/resolv.conf
0 lrwxrwxrwx 1 root root 32 апр 15 17:14 /etc/resolv.conf -> /run/systemd/resolve/resolv.conf

Взял resolv из https://wiki.archlinux.org/index.php/Resolv.conf (по привычке гугловские). Перезапустил демон и refresh-key заработал)
Я сам пользуюсь NetworkManager + dnsmasq. dnsmasq как демон кешью dns(https://wiki.archlinux.org/index.php/Dnsmasq_%28%D0%A0%D1%83%D1%81%D1%81%D0%BA%D0%B8%D0%B9%29). Вот думаю что делать с /etc/resolv.conf, ведь /run/systemd ето tmpfs.

Ага, есть у systemd друг /usr/lib/systemd/systemd-resolved (systemd-resolved.service) автоматом создает нужный файл.

Перезагружаемся(не активировав сервиса), (файла resolv нет) проверяем
pacman-key --refresh-keys
gpg: обновление 91 ключа из hkp://pool.sks-keyservers.net
gpg: сбой при обновлении с сервера ключей: Нет такого файла или каталога
==> ОШИБКА: Не удалось обновить указанный локальный ключ с сервера ключей.

Запустим демон.
systemctl enable systemd-resolved.service
systemctl start systemd-resolved.service

И перезагружаемся!! (или убиваем dirmngr и запускаем вручную).
Все) Правда resolv принел вид
# Generated by resolvconf
nameserver 127.0.0.1
Но робит.
 
Зарегистрироваться или войдите чтобы оставить сообщение.