<div> </div><div> </div><div>31.03.2020, 22:05, "Alexey Shabalin" &lt;a.shabalin@gmail.com&gt;:</div><blockquote>3) systemd-resolved</blockquote><div>Честно говоря, это чень пожоже на то, что люди взяли простую (снаружи, но весьма не простую внутри) вещь и превратили ее в лютый -здец, в котором черт сломает не только конечности, но и рога и глаза и мозг. Мне, например, сходу не удается уследить за всеми этими хитросплетениями конфигов, лежащих в разных местах и как-то хитро друг на друга влияющих. А главное, я не могу понять - зачем...   Но... Как-бы не systemd обсуждаем.</div><div> <blockquote><p>/etc/resolv.conf он тоже умеет читать,<br />но никак его не модифицирует.</p></blockquote><div>Первая строка системного /etc/resolv.conf (после того как в него применились настройки DHCP):</div><div># This file is managed by man:systemd-resolved(8). Do not edit.</div><blockquote><p>Скажем так, у systemd-resolved свой resolv.conf, который находиться в<br />/run/systemd/resolve. И не один :)<br />Что бы продолжал работать glibc с nss-модулем dns, systemd-resolved<br />может предоставить для него resolv.conf<br />а) статический /lib/systemd/resolv.conf в котором указан nameserver 127.0.0.53.<br />сделав симлинк /etc/resolv.conf - &gt; /lib/systemd/resolv.conf мы<br />укажем нашей системе использовать systemd-resloved как локальный<br />dns-сервер.<br />б) сгенерированный /run/systemd/resolve/stub-resolv.conf<br />Вот на него более правильно делать симлинк /etc/resolv.conf. В нем<br />также указан nameserver 127.0.0.53, но еще может быть указаны домены<br />поиска(search example.com)<br />в) сгенерированный /run/systemd/resolve/resolv.conf<br />В нем указаны реальные DNS сервера. Т.е. скопировав в /etc/resolv.conf<br />(или симлинк) приложения(glibc nss-dns) перестанут использовать<br />локальный кэширующий dns-сервер systemd-resolved и начнут напрямую<br />использовать указанные сервера.<br />Информация в этот сгенерированный файл попадает из файлов<br />/etc/systemd/network/*.network и /etc/systemd/resolved.conf (DNS=...,<br />Domains=...)<br />Эти же данные используются и для работы самого systemd-resolved.<br /><br />4) NetworkManager.<br />NetworkManager по-умолчанию использует встроенный dhcp-клиент, но<br />может и внешний (можно определить в<br />/etc/NetworkManager/conf.d/dhcp-client.conf<br />[main]<br />dhcp=dhcpcd или dhclient (поумолчанию internal)<br />)<br />Так же он может использовать dnsmasq, unbound или systemd-resolved в<br />качестве локального dns-сервера (dns=dnsmasq).<br />При этом не надо отдельно стартовать dnsmasq или unbound, он их сам<br />запустит и настроит (подсунет конфиг).<br />если /etc/resolv.conf симлинк на один из systemd-resolved конфиг, NM<br />это понимает и использует systemd-resolved(не трогает<br />/etc/resolv.conf)<br />А вот если не симлинк, то начинает его именять (указывает nameserver<br />для статического или DHCP адреса) используя openresolv(собран с<br />параметром --with-config-dns-rc-manager-default=resolvconf) .<br />По аналогии с systemd-resolved генерирует resolv.conf в<br />/run/NetworkManager/resolv.conf и /run/NetworkManager/no-stub-resolv.conf<br /><br />5) update_chrooted.<br />Наши замечательные ALT особенности :)<br />Множество сервисов и отдельных программ(например ping) запускаются в chroot.<br />В этот chroot должны быть скопированы и библиотеки, и настройки для<br />этих библиотек, в частности resolv.conf.<br />Т.е. ping не использует /etc/resolv.conf, а использует<br />/var/resolv/etc/resolv.conf.<br />Нам очень важно держать в chroot'ах resolv.conf синхронным c с<br />основной системой.<br />Вроде все утилиты, обновляющие /etc/resolv.conf обучены вызывать<br />update_chrooted.<br />- Первая глобальная проблема - update_chroot не предполагает симлинка<br />/etc/resolv.conf.<br />Приплыли. Большая часть проблем отпала :) (точнее наоборот появилась).<br />Подождем еще 3 месяца и баге будет 3 года. Спасибо ldv@.<br /><a href="https://bugzilla.altlinux.org/show_bug.cgi?id=33591">https://bugzilla.altlinux.org/show_bug.cgi?id=33591</a><br />- Вторая проблема, как изменение resolv.conf обрабатывать в systemd.<br />Если используются etcnet или NetworkManager то они за собой дёргают<br />update_chrooted.<br />А вот systemd-networkd и systemd-resolved не имеют возможности<br />запустить какой либо хук.<br /><br />6) дополнительные сервисы в systemd<br />- Для решения второй проблемы в пункте 5<br />systemd умеет отслеживать изменение файлов и запускать по событию сервис.<br />были написаны сервисы altlinux-libresolv.path(отслеживает изменения) и<br />altlinux-libresolv.service (запускает /etc/chroot.d/resolv.conf).<br />- для обновления /etc/resolv.conf без использования openresolv<br />были написаны сервисы altlinux-simpleresolv.path и altlinux-simpleresolv.service<br />- для обновления /etc/resolv.conf с ипользование openresolv<br />были написаны сервисы altlinux-openresolv.path и altlinux-openresolv.service<br />У меня и коллег есть претензии к этим сервисам, и надо обдумать и<br />переписать их. Предложения приветствуются.<br /><br /><br />Подведение итогов и рекомендации:<br />- systemd-resolved работает в связке с systemd-networkd. Можно конечно<br />и без, но это создание дополнительных трудностей.<br />Проще рекомендовать использовать systemd-resolved только с systemd-networkd.<br />- при использовании etcnet, не пытайтесь использовать<br />systemd-resolved. Можно конечно, но это создание дополнительных<br />трудностей.<br />Просто удалите пакет systemd-networkd.<br />- NetworkManager вроде должен уметь работать в любых условиях с кем угодно.<br /> </p>--<br />Alexey Shabalin<br />_______________________________________________<br />Sysadmins mailing list<br /><a href="mailto:Sysadmins@lists.altlinux.org">Sysadmins@lists.altlinux.org</a><br /><a href="https://lists.altlinux.org/mailman/listinfo/sysadmins">https://lists.altlinux.org/mailman/listinfo/sysadmins</a></blockquote></div>