Ошибся, на sisyphus перепроверил ещё раз, там скорость работы нормальная, как в p11. Проблема только в p11+387440, т. е. возможно исправляется в admc-0.21.0-alt1.x86_64 или зависит от какого-то другого пакета.

Перепроверил также в p11+387440 на свежеразвёрнутом домене, не воспроизвелось повторно. Возможно, плавающая ошибка, или зависит от каких-либо конкретных настроек, выполненных в домене при других проверках.

Хотелось бы локализовать проблемы.
Плавающую багу искать тяжело.

Наверное, стоит проверить статус клиента с помощью diag-domain-client.

Сейчас нет доступа к тем клиентам, где воспроизводилось. Воспроизводилось на всех 4 клиентах, т. е. возможно дело было и в сервере.

diag-domain-client/controller выполнял до обнаружения данной проблемы, всё было успешно за исключением:


1. Некорректной работы самих тестов:

* https://bugzilla.altlinux.org/51685
* https://bugzilla.altlinux.org/51573


2. Ошибок/предупреждений в тестах:

[WARN] # diag-domain-client --verbose check_nameservers 

(samba.testdomain недоступен на вышестоящих DNS-серверах, ожидаемо)


[WARN] # diag-domain-controller is_there_way_to_cache_kerberos_tickets
The type of caching of Kerberos tickets is set: keyring.
Possible problems with caching of Kerberos tickets.

(позже устанавливал `kerberos method = system keytab` для проверки https://bugzilla.altlinux.org/55111 - возможно из-за этого?)


[FAIL] # diag-domain-controller is_resolve_local 
Error: the resolv.conf file does not contain the nameserver 127.0.0.1 line.

(ожидаемо, `nameserver 127.0.0.1` убирается специально)

Created attachment 19190 [details]
wireshark (2) bug

При проверке в новой сборке p11+387440.5 ошибка снова воспроизвелась на всех клиентах.

Ошибка связана с DC и/или репликой, т. к.:
* При работающем ADMC на клиенте, если выполнить откат серверов до состояния сразу после введения клиентов в домен (1), проблема перестаёт воспроизводится.
* Как только выполняется откат до состояния, в котором ошибка воспроизводится (2), она сразу начинает воспроизводится, без перезапуска ADMC.

Попробовал воспроизвести на (1) (и наоборот исправить на (2)), выполняя шаги, которые выполнял при проверке (или обратные), но пока не удалось установить причину.

Однако известно, что:
* Результат `diag-domain-{client,controller}` не изменился.
* Перезагрузка серверов и клиентов не влияет на воспроизводимость.
* В терминале `$ admc` и в `# journalctl -f` вывода при возникновении проблемы нет.
* Никаких ошибок в интерфейсе ADMC не возникает (как, например, при отсутствии подключения к серверу). Просто начинает тормозить после 1-2 нажатий, и пока какой-то внутренний процесс не завершится и действия не обработаются, висит.
* Повышенной загрузки по памяти или CPU на клиенте, сервере и реплике не наблюдается.

Прикрепляю запись экрана с Wireshark в состояниях (2) и (1). В (2) быстро выполняются запросы DNS, а затем после долгой задержки клиент начинает быстро выполнять запросы LDAP и пр. В (1) все запросы выполняются сразу. При этом ответы на DNS-запросы идентичные (за исключением, конечно, Transaction ID).

Есть какие-то дополнительные способы выполнить диагностику проблемы, возможно как-то сделать profiling admc?

Created attachment 19191 [details]
wireshark (1) ok

Для диагностики поведения admc, хотелось бы исключить особенности реализации запросов в ui-приложении. Для этого необходимо провести анализ скорости выполнения запросов через ldapsearch к каждому из контроллеров.

Сценарий проверки:

1) Получаем список всех ldap-служб в домене:

$ host -t srv _ldap._tcp.domain.alt
_ldap._tcp.domain.alt has SRV record 0 100 389 dc0.domain.alt.
_ldap._tcp.domain.alt has SRV record 0 100 389 dc1.domain.alt.

2) Проверяем аналогичный запрос для kdc с каждого из полученных dc (не обязательно именно такой запрос, просто другой, можно разные попробовать):

$ host -t srv _kerberos._udp.domain.alt dc0.domain.alt
$ host -t srv _kerberos._udp.domain.alt dc1.domain.alt

3) Выполняем kinit (чистим кеш ключей для сервисов), проверяем через klist доступный tgt:

$ kinit
$ klist

4) Пробуем разные ldap-запросы к разным КД, наблюдаем за поведением (наличием задержек):

$ ldapsearch -LL -Y GSSAPI -H ldap://dc0.domain.alt -b "dc=domain,dc=alt" "objectClass=user" sAMAccountName | grep ^sAMAccountName

$ ldapsearch -LL -Y GSSAPI -H ldap://dc1.domain.alt -b "dc=domain,dc=alt" "objectClass=user" sAMAccountName | grep ^sAMAccountName

(разумеется правим domain.alt и dc=domain,dc=alt под свой домен)

5) Смотрим через klist вновь выданный набор сервисных ключей.

$ klist
__________________

Если задержки после обновления будут выявлены, то admc из рассмотрения проблемы исключаем, проблема локализуется.

PS: А что у вас тут ожидаемого?

> [FAIL] # diag-domain-controller is_resolve_local 
> Error: the resolv.conf file does not contain the nameserver 127.0.0.1 line.
> 
> (ожидаемо, `nameserver 127.0.0.1` убирается специально)

Зачем вы это специально делаете? Оно же нужно только на реплике момент её введения в домен. В штатном режиме другой dns на резолвере контроллера домена - это риски. В случае, если dns-резолвер внешний ляжет, то КД будет неработоспособен из-за этой "интересной" настройки. Так делают, когда сеть по-особенному настраивают. Ну, и принимают на себя все соответствующие риски.

Спасибо.

Про `nameserver 127.0.0.1`:

При разворачивании Samba dc + replica (internal dns) использовался `nameserver <dc-ip>`, т. е. DNS-сервер не внешний, но вероятно такая настройка тоже неидеальна.
* Поменял на 127.0.0.1 на DC.
* Поменял на 127.0.0.1 на реплике после введения её в домен (до этого используется <dc-ip>).
* На клиентах, если строка `nameserver 127.0.0.1` имеется, продолжает удаляться, используется DNS-сервер DC.

После этого тест `diag-domain-controller is_resolve_local` проходит успешно.

Про проверки с замедлением/ADMC напишу отдельно.

Created attachment 19232 [details]
Вывод тестовых шагов

С помощью комментарий #7 разобрался, в чём именно проблема с зависанием ADMC и как её воспроизвести.

Изначально проверял на snapshot (2) виртуальных машин с [p11+387440.5], где воспроизвелась ошибка (на .6 ещё не встретился с этой ошибкой), сравнивая с (1).

После этого воспроизвёл в [p11] [p11+387440.6] [sisyphus], т. е. не является регрессом.

---

На этапе выполнения ldapsearch (шаг 4) проверка затрудняется ошибкой https://bugzilla.altlinux.org/50727, поэтому перед проверкой требуется workaround вида (и для dc, и для dc2; выполняется только на dc):

[dc]# dc_ip="$(hostname -i)" dc2_ip="<ip>" auth="administrator%пароль" realm="samba.testdomain" && \
  apt-get install -y python3-module-setproctitle && \
  dc=(${dc_ip//./ })   dc_zone="${dc[2]}.${dc[1]}.${dc[0]}.in-addr.arpa"     && \
  dc2=(${dc2_ip//./ }) dc2_zone="${dc2[2]}.${dc2[1]}.${dc2[0]}.in-addr.arpa" && \
  samba-tool dns zonecreate "$(hostname)" "$dc_zone"  -U "$auth"; \
  samba-tool dns zonecreate "$(hostname)" "$dc2_zone" -U "$auth"; \
  samba-tool dns add        "$(hostname)" "$dc_zone"   "${dc[3]}" PTR "dc.$realm"  -U "$auth"; \
  samba-tool dns add        "$(hostname)" "$dc2_zone" "${dc2[3]}" PTR "dc2.$realm" -U "$auth"; \
  samba-tool dns query      "$(hostname)" "$dc_zone"   "${dc[3]}" PTR -U "$auth"; \
  samba-tool dns query      "$(hostname)" "$dc2_zone" "${dc2[3]}" PTR -U "$auth"

(Возможно, это требуется выполнять всегда при разворачивании Samba DC?)

Примечание: ADMC, GPUI работают и без данного workaround.

---

Для проверки использовал:

# admin_password="test" r1="samba" r2="testdomain" realm="$r1.$r2" time="time -f %es\\n --" && \
  echo "# 0."   && $time kdestroy && \
  echo "# 1."   && $time host -t srv "_ldap._tcp.$realm" && \
  echo "# 2."   && $time host -t srv "_kerberos._udp.$realm" "dc.$realm" && \
  echo "# 3.1." && $time echo "$admin_password" | kinit Administrator && \
  echo "# 3.2." && $time klist && \
  echo "# 4."   && $time ldapsearch -LL -Y GSSAPI -H "ldap://dc.$realm" -b "dc=$r1,dc=$r2" "objectClass=user" sAMAccountName | grep ^sAMAccountName && \
  echo "# 5."   && $time klist

Прикрепляю вывод, кратко результаты такие:
* На шаге 1 выводится только основной DC, а не 2; не уверен в причине этого.
* Когда ошибка воспроизводится, шаг 4 выполняется на ~3s дольше.
* Но основная проблема, похоже, на шаге 2 (см. подробнее ниже).

Где ошибка не воспроизводится, там до успешного завершения запроса `connection refused` к ipv6-адресу, занимает 0.02s:

> # 2.
> ;; communications error to <dc-ipv6>#53: connection refused
> ;; communications error to <dc-ipv6>#53: connection refused
> Using domain server:
> Name: dc.samba.testdomain
> Address: <dc-ipv4>#53
> Aliases:
>
> _kerberos._udp.samba.testdomain has SRV record 0 100 88 dc.samba.testdomain.
> 0.02s

А где воспроизводится, там `timed out`, занимает 10.02s (зависает именно до достижения timeout):

> # 2.
> ;; communications error to <dc-ipv6>#53: timed out
> ;; communications error to <dc-ipv6>#53: timed out
> Using domain server:
> Name: dc.samba.testdomain
> Address: <dc-ipv4>#53
> Aliases:
>
> _kerberos._udp.samba.testdomain has SRV record 0 100 88 dc.samba.testdomain.
> 10.02s

---

В `/etc/resolv.conf` клиента нет IPv6-адресов, поэтому сначала не понял, откуда клиент узнаёт IPv6-адрес DC.

Но с помощью `tshark` увидел, что `host` сначала спрашивает у DNS (в данном случае DC) IPv6-адрес (AAAA) `dc.samba.testdomain`, а потом уже по полученному адресу выполняет запрос `_kerberos._udp.samba.testdomain`:

> # tshark -f 'udp port 53'
> Running as user "root" and group "root". This could be dangerous.
> Capturing on 'ens19'
> ^Z
> [1]+  Остановлен    tshark -f 'udp port 53'

> # host -6 -t srv _kerberos._udp.samba.testdomain dc.samba.testdomain
> ;; communications error to 2a0c:88c0:2:2000:6465:c1ff:fe5f:fd9e#53: connection refused
> ;; communications error to 2a0c:88c0:2:2000:6465:c1ff:fe5f:fd9e#53: connection refused
> ;; no servers could be reached

> # fg
> tshark -f 'udp port 53'
>     1 0.000000000 <client-ipv4> → <dc-ipv4> DNS 79 Standard query 0xc22c AAAA dc.samba.testdomain
>     2 0.001058139 <dc-ipv4> → <client-ipv4> DNS 154 Standard query response 0xc22c AAAA dc.samba.testdomain AAAA <dc-ipv6> SOA dc.samba.testdomain
>     3 0.002631309 <client-ipv6> → <dc-ipv6> DNS 111 Standard query 0xab32 SRV _kerberos._udp.samba.testdomain
>     4 0.004063574 <client-ipv6> → <dc-ipv6> DNS 111 Standard query 0xab32 SRV _kerberos._udp.samba.testdomain

---

Далее, посмотрев `ip -c a`, увидел, что, когда воспроизводится ошибка, на DC нет IPv6-адреса (вообще).

Причина этого в том, что при проверке https://bugzilla.altlinux.org/51190 по шагам https://bugzilla.altlinux.org/show_bug.cgi?id=51190#c1 отключается IPv6 на DC:

# echo 'net.ipv6.conf.all.disable_ipv6 = 1' >> /etc/sysctl.conf && \
    sysctl -f

Похоже, это не столько необходимо, сколько сделано для упрощения проверки, чтобы не создавать ещё файл для IPv6-адреса DC. Улучшу эту проверку, чтобы не требовалось отключать IPv6.

После удаления строки `net.ipv6.conf.all.disable_ipv6 = 1` из `/etc/sysctl.conf` и выполнения `# reboot` проблема решается.

---

То, что когда ошибка не воспроизводится, к IPv6 DC `connection refused` - ожидаемо из-за настройки в `/etc/samba/smb.conf` на DC, которая делается для обхода ошибки https://bugzilla.altlinux.org/43863:

>    interfaces = <dc-ipv4> 127.0.0.1
>    bind interfaces only = yes

---

Остаются вопросы: должно ли быть такое замедление и корректно ли поведение Samba Internal DNS?

* Команда `host`, думаю, работает сама по себе корректно, предпочитая IPv6.
** Возможно ли как-то обойти эту проблему в ADMC? `host` поддерживает опцию `-4`, хотя использовать её всегда, думаю, не будет правильным.

* Однако корректно ли, что встроенный DNS Samba DC отдаёт в ответ на запрос AAAA свой IPv6-адрес, если он на нём не слушает (исходя из interfaces + bind interfaces only)?

* Более того, корректно ли, что такой ответ присутствует, даже если у Samba DC вообще нет IPv6-адреса в данный момент (IPv6 отключён через sysctl)?
** Возникает также дополнительный вопрос, что произойдёт, если IPv6-адрес DC поменяется - будет ли отдаваться старый?

> * Однако корректно ли, что встроенный DNS Samba DC отдаёт в ответ на запрос AAAA свой IPv6-адрес, если он на нём не слушает (исходя из interfaces + bind interfaces only)?

Стоит отметить, что при использовании BIND9_DLZ (замечено на samba-dc-4.21.9-alt1.x86_64, bind-9.18.39-alt1.x86_64) такого не происходит. Если Samba DC не настроен слушать на IPv6, IPv6-адрес не отдаётся в ответе.

Т. е. такое поведение именно у Internal DNS.