Ulin |
|
Темы:
3
Сообщения:
81
Участник с: 16 июня 2016
|
Хотя по http работает. Хост думаю норм
|
vasek |
|
Темы:
48
Сообщения:
11320
Участник с: 17 февраля 2013
|
UlinВряд ли сломан — просто не пускает на сервер, судя по логу вместо сообщения типа ты получаешь сообщение
UPD … Опять тебя обманул, у меня все работает и из под root ….. Вчера был невнимателен — не смог получить ключ, видимо ошибся в команде — сейчас 2 раза проверил, все проходит нормально. И подкорректировал выше свое сообщение vasekне выкинуло, а вышел сам, через Q. Писал под впечатлением, что не смог получить ключ. Ошибок накапливается у меня все больше и больше — пора мне завязывать. Если что встречу толковое, отпишусь. PS ... только сейчас обратил внимание на символ - � - это что, глюк или что с кодировкой??? - а не может быть причина в этом? PSS ... а выход вижу один - искать почему не пускает на сервер - можно опять потрейсить с фильтром network и смотреть вызовы connect, accept и др. + другие сетевые утилиты ...
Ошибки не исчезают с опытом - они просто умнеют
|
vasek |
|
Темы:
48
Сообщения:
11320
Участник с: 17 февраля 2013
|
Уважаемые админы, чувствую, что я уже достал своей писаниной - все, на этом заканчиваю.
Ошибки не исчезают с опытом - они просто умнеют
|
Ulin |
|
Темы:
3
Сообщения:
81
Участник с: 16 июня 2016
|
Проблема не решена. С кодировками ок utf-8 работае. |
vasek |
|
Темы:
48
Сообщения:
11320
Участник с: 17 февраля 2013
|
UlinВыход вижу один, рекомендую заняться анализом доступа на сервер ключей — посмотреть прохождение и чтение пакетов, используя нестандартные сетевые утилиты, например, самая простая и не требующая навыков работы - ngrep и самая сложная, требующая определенных знаний и навыков работы - wireshark. Плюс к этому, как уже писал, дополнительно к этим утилитам не забывать и о strace, в части анализа сетевых системных вызовов. Мое мнение — нужно понять, что там на сервере ключей делается, грубо говоря, посмотреть, как идет обмен пакетами в обе стороны и чем это все заканчивается.
Ошибки не исчезают с опытом - они просто умнеют
|
Ulin |
|
Темы:
3
Сообщения:
81
Участник с: 16 июня 2016
|
Wireshark знаю. пользовался. Ок. спасибо буду пробовать. |
Ulin |
|
Темы:
3
Сообщения:
81
Участник с: 16 июня 2016
|
Wireshark не показал никакого намека на внешнее соединение. Да и вообще были логи с локаль вайфая только. ngrep действительно очень прост и он тоже молчит. |
vasek |
|
Темы:
48
Сообщения:
11320
Участник с: 17 февраля 2013
|
UlinТогда попробуй посмотреть, что выдает ngrep - а для этого запусти так: Перед началом - закрыть приложения, проявляющие сетевую активность и # killall dirmngr - запусти два терминала - в 1-ом терминале # ngrep > ~/ngrep.log - перейти на 2-ой терминал и $ gpg --debug 1024 --keyserver hkps://hkps.pool.sks-keyservers.net --search-keys B4322F04D67658D8 и после отработки/завершения, закрыть запущенные приложения в обоих терминалах - ну и смотри файл ~/ngrep.log …..
Ошибки не исчезают с опытом - они просто умнеют
|
vasek |
|
Темы:
48
Сообщения:
11320
Участник с: 17 февраля 2013
|
В части ngrep — просто хотел, что бы ты посмотрел движение пакетов — на начальном уровне анализа с его помощью можно получить стартовую информацию ... Без обид, что то потянуло на стариковские Если есть желание разбираться с пакетами и их прохождением, то рекомендую использовать самый лучший для этих целей инструмент (лучшего я еще не встречал) — язык не поворачивается назвать утилитой — это программа, точнее программный комплекс, scapy, который позволяет самому готовить пакеты и отправлять их, смотреть доходят ли они до адресата, вплоть до трассировки маршрута и многое другое (о чем не говорят, чему не учат в школе) …. но требует тщательного изучения. UPD ... но это все анализ, а вот для выяснения причины (или хотя бы определения какого то причинного фактора) без strace не обойтись.
Ошибки не исчезают с опытом - они просто умнеют
|
Ulin |
|
Темы:
3
Сообщения:
81
Участник с: 16 июня 2016
|
Привет) я снова здеся. Снова решил разобратся... Решение оказалось очень даже простым) Пишем Получаем Пишем под рутом Появляются интересные логи Послушаляс варнинга, Удалил /etc/dirmngr, и заодно сделал touch /etc/pacman.d/gnupg/dirmngr_ldapservers.confНичего не изменилось, пробую refresh key, и тут в открытом dirmng появляются новые логищя
Все вродебы нормально, но тут смутило меня dirmngr[5199.5]: failed to load '/etc/resolv.conf': Нет такого файла или каталога Тоесть он зачем-то использует ети dns..
Взял 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 нет) проверяем
Запустим демон.
И перезагружаемся!! (или убиваем dirmngr и запускаем вручную). Все) Правда resolv принел вид Но робит.
|