[sisyphus] приключения resolv.conf в ALT

[sisyphus] приключения resolv.conf в ALT

[Alexey Shabalin]

> PS: следующим письмом попробую подробно описать наши кувыркания с resolv.conf.
> дождитесь его, прежде чем отвечать :)

Может это куда-то на wiki перенести. Лучшее понимание механизмов
позволит быстрее диагностировать ошибки.

Преобразование имен хостов в адреса занимается glibc на основе
различных источников данных (/etc/hosts, mDNS, winbind, dns, ldap и
т.п.). Это модульная система. Можно добавить много различных модулей.
Эти источники указаны в "grep hosts /etc/nsswitch.conf"
hosts:      files dns myhostname
Например, добавив в "hosts:" mymachines (пакет libnss-mymachines) мы
сможем обращаться к нашим контейнерам systemd-nspawn по именам.
Мы сейчас говорим о модуле dns (/lib{,64}/libnss_dns.so) который
слинкован с libresolv. Именно в libresolv определено использование
/etc/resolv.conf.
С вводной частью закончили, давайте перейдём к практике и рассмотрим
кто и как наполняет этот /etc/resolv.conf

1) etcnet. 2 варианта, для статической настройки или DHCP.
- для статики все просто, файл копируется из
/etc/net/ifaces/foo/resolv.conf в /etc/resolv.conf
- для DHCP посложнее. dhcpcd получает данные от dhcp-сервера, а дальше
с помощью хуков (/lib/dhcpcd/dhcpcd-hooks/20-resolv.conf) обновляет
/etc/resolv.conf

2) openresolv
Был придуман для того, что бы во время работы при смене DNS удобно
управлять /etc/resolv.conf. Оправдан, кода вы одни dns получили от
dhcp сервера, а другие dns от vpn соединения.
Когда у нас происходит настройка на dns-сервера только один раз при
загрузке, то использовать openresolv нет необходимости. Возможно даже
вредно, т.к. вносит еще один элемент(прокладку) во всю эту хрупкую
конструкцию.
При наличии openresolv в системе, etcnet начинает автоматически
использовать её, поэтому копирование /etc/net/ifaces/foo/resolv.conf в
/etc/resolv.conf или наполнение /etc/resolv.conf данными от DHCP
сервера происходит не напрямую, а через вызов /sbin/resolvconf.
Надо еще упомянуть, что openresolv умеет готовить конфиги для dnsmasq,
unbound, pdns, bind, если они используются как локальные dns-сервера.

3) systemd-resolved
- systemd-resolved по сути маленьки локальный кэширующий dns-сервер,
принимающий запросы на 127.0.0.53:53. Его можно с натяжкой сравнить с
dnsmasq, unbound, knot-reolver(конечно они гораздо мощнее и гибче), но
он умеет, например, DNSSEC и DNSOverTLS.
- Кроме этого он предоставляет API для взаимодействия напрямую через
вызовы библиотеки, а не через udp запросы.
Добавив в nsswitch.conf
hosts: resolve (пакет libnss-resolve)
мы сможем резолвить имена без (/lib{,64}/libnss_dns.so) и без
обращения к /etc/resolv.conf. /etc/resolv.conf он тоже умеет читать,
но никак его не модифицирует.
Скажем так, у systemd-resolved свой resolv.conf, который находиться в
/run/systemd/resolve. И не один :)
Что бы продолжал работать glibc с nss-модулем dns, systemd-resolved
может предоставить для него resolv.conf
а) статический /lib/systemd/resolv.conf в котором указан nameserver 127.0.0.53.
сделав симлинк /etc/resolv.conf - >  /lib/systemd/resolv.conf мы
укажем нашей системе использовать systemd-resloved как локальный
dns-сервер.
б) сгенерированный /run/systemd/resolve/stub-resolv.conf
Вот на него более правильно делать симлинк /etc/resolv.conf. В нем
также указан nameserver 127.0.0.53, но еще может быть указаны домены
поиска(search example.com)
в) сгенерированный /run/systemd/resolve/resolv.conf
В нем указаны реальные DNS сервера. Т.е. скопировав в /etc/resolv.conf
(или симлинк) приложения(glibc nss-dns) перестанут использовать
локальный кэширующий dns-сервер systemd-resolved и начнут напрямую
использовать указанные сервера.
Информация в этот сгенерированный файл попадает из файлов
/etc/systemd/network/*.network и /etc/systemd/resolved.conf (DNS=...,
Domains=...)
Эти же данные используются и для работы самого systemd-resolved.

4) NetworkManager.
NetworkManager по-умолчанию использует встроенный dhcp-клиент, но
может и внешний (можно определить в
/etc/NetworkManager/conf.d/dhcp-client.conf
[main]
dhcp=dhcpcd или dhclient (поумолчанию internal)
)
Так же он может использовать dnsmasq, unbound или systemd-resolved в
качестве локального dns-сервера (dns=dnsmasq).
При этом не надо отдельно стартовать dnsmasq или unbound, он их сам
запустит и настроит (подсунет конфиг).
если /etc/resolv.conf симлинк на один из systemd-resolved конфиг, NM
это понимает и использует systemd-resolved(не трогает
/etc/resolv.conf)
А вот если не симлинк, то начинает его именять (указывает nameserver
для статического или DHCP адреса) используя openresolv(собран с
параметром --with-config-dns-rc-manager-default=resolvconf) .
По аналогии с systemd-resolved генерирует resolv.conf в
/run/NetworkManager/resolv.conf и /run/NetworkManager/no-stub-resolv.conf

5) update_chrooted.
Наши замечательные ALT особенности :)
Множество сервисов и отдельных программ(например ping) запускаются в chroot.
В этот chroot должны быть скопированы и библиотеки, и настройки для
этих библиотек, в частности resolv.conf.
Т.е. ping не использует /etc/resolv.conf, а использует
/var/resolv/etc/resolv.conf.
Нам очень важно держать в chroot'ах resolv.conf синхронным c с
основной системой.
Вроде все утилиты, обновляющие /etc/resolv.conf обучены вызывать
update_chrooted.
- Первая глобальная проблема - update_chroot не предполагает симлинка
/etc/resolv.conf.
Приплыли. Большая часть проблем отпала :) (точнее наоборот появилась).
Подождем еще 3 месяца и баге будет 3 года. Спасибо ldv@.
https://bugzilla.altlinux.org/show_bug.cgi?id=33591
- Вторая проблема, как изменение resolv.conf обрабатывать в systemd.
Если используются etcnet или NetworkManager то они за собой дёргают
update_chrooted.
А вот systemd-networkd и systemd-resolved не имеют возможности
запустить какой либо хук.

6) дополнительные сервисы в systemd
- Для решения второй проблемы в пункте 5
systemd умеет отслеживать изменение файлов и запускать по событию сервис.
были написаны сервисы altlinux-libresolv.path(отслеживает изменения) и
altlinux-libresolv.service (запускает /etc/chroot.d/resolv.conf).
- для обновления /etc/resolv.conf без использования openresolv
были написаны сервисы altlinux-simpleresolv.path и altlinux-simpleresolv.service
- для обновления /etc/resolv.conf с ипользование openresolv
были написаны сервисы altlinux-openresolv.path и altlinux-openresolv.service
У меня и коллег есть претензии к этим сервисам, и надо обдумать и
переписать их. Предложения приветствуются.


Подведение итогов и рекомендации:
- systemd-resolved работает в связке с systemd-networkd. Можно конечно
и без, но это создание дополнительных трудностей.
Проще рекомендовать использовать systemd-resolved только с systemd-networkd.
- при использовании etcnet, не пытайтесь использовать
systemd-resolved. Можно конечно, но это создание дополнительных
трудностей.
Просто удалите пакет systemd-networkd.
- NetworkManager вроде должен уметь работать в любых условиях с кем угодно.

--
Alexey Shabalin

Re: [sisyphus] приключения resolv.conf в ALT

[Sergey Bolshakov]

>>>>> "Alexey" == Alexey Shabalin <a.shabalin-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> writes:

 >> PS: следующим письмом попробую подробно описать наши кувыркания с resolv.conf.
 >> дождитесь его, прежде чем отвечать :)

[skipped]

 > 3) systemd-resolved

Кроме того, из коробки у нас есть llmnr и, если разрешить, mdns
(страдальцы по avahi могут наконец перестать страдать):
i.e. resolvectl query [-p llmnr] <host> эффективно служит
заменой ping, улучшенным у нас до состояния нирваны.
systemd -- лучшее, что случилось с линупсом за последние годы,
истинно говорю я вам.

[rest skipped]

-- 

[sisyphus] [JT] Re: приключения resolv.conf в ALT

[Michael Shigorin]

On Wed, Apr 01, 2020 at 03:15:21PM +0300, Sergey Bolshakov wrote:
> systemd -- лучшее, что случилось с линупсом за последние годы,
> истинно говорю я вам.

У разных людей всё так же различается ответ на древний вопрос:
"что есть истина?".

По-моему -- худшее, т.к. реальные технические проблемы
решались неграмотными людьми (например, не имеющими отношения
к системному администрированию разработчиками в стиле хуже
комитетного), некоторые из которых поражены нарциссизмом
в терминальной стадии, судя по внешним проявлениям;
ну и внедрение в характерно демократическом стиле
"не захочет -- заставим" как не-вишенка.

Но тут, я думаю, можно точно согласиться на несогласии.

-- 
 ---- WBR, Michael Shigorin / http://altlinux.org
  ------ http://opennet.ru / http://anna-news.info

Re: [sisyphus] приключения resolv.conf в ALT

[Mikhail Efremov]

On Tue, 31 Mar 2020 22:05:17 +0300 Alexey Shabalin wrote:
> 4) NetworkManager.
> NetworkManager по-умолчанию использует встроенный dhcp-клиент, но
> может и внешний (можно определить в
> /etc/NetworkManager/conf.d/dhcp-client.conf
> [main]
> dhcp=dhcpcd или dhclient (поумолчанию internal)
> )
> Так же он может использовать dnsmasq, unbound или systemd-resolved в
> качестве локального dns-сервера (dns=dnsmasq).
> При этом не надо отдельно стартовать dnsmasq или unbound, он их сам
> запустит и настроит (подсунет конфиг).

Замечу, что эта поддержка локальных DNS-серверов у нас оторвана именно
потому, что есть openresolv и не надо делать странные вещи в самом NM.
С systemd-resolved должно работать.

-- 
WBR, Mikhail Efremov

Re: [sisyphus] приключения resolv.conf в ALT

[Vladimir D. Seleznev]

On Tue, Mar 31, 2020 at 10:05:17PM +0300, Alexey Shabalin wrote:
> > PS: следующим письмом попробую подробно описать наши кувыркания с resolv.conf.
> > дождитесь его, прежде чем отвечать :)
> 5) update_chrooted.
> Наши замечательные ALT особенности :)
> Множество сервисов и отдельных программ(например ping) запускаются в chroot.
> В этот chroot должны быть скопированы и библиотеки, и настройки для
> этих библиотек, в частности resolv.conf.
> Т.е. ping не использует /etc/resolv.conf, а использует
> /var/resolv/etc/resolv.conf.
> Нам очень важно держать в chroot'ах resolv.conf синхронным c с
> основной системой.
> Вроде все утилиты, обновляющие /etc/resolv.conf обучены вызывать
> update_chrooted.

Может быть стоит написать некий update_chrootd, который следил бы за
всеми файлами, которые должны быть в чруте, и при их обновлении обновлял
бы чрут?

-- 
   WBR,
   Vladimir D. Seleznev

Re: [sisyphus] [devel] приключения resolv.conf в ALT

[Denis Medvedev]

03.04.2020 13:28, Vladimir D. Seleznev пишет:
> On Tue, Mar 31, 2020 at 10:05:17PM +0300, Alexey Shabalin wrote:
>>> PS: следующим письмом попробую подробно описать наши кувыркания с resolv.conf.
>>> дождитесь его, прежде чем отвечать :)
>> 5) update_chrooted.
>> Наши замечательные ALT особенности :)
>> Множество сервисов и отдельных программ(например ping) запускаются в chroot.
>> В этот chroot должны быть скопированы и библиотеки, и настройки для
>> этих библиотек, в частности resolv.conf.
>> Т.е. ping не использует /etc/resolv.conf, а использует
>> /var/resolv/etc/resolv.conf.
>> Нам очень важно держать в chroot'ах resolv.conf синхронным c с
>> основной системой.
>> Вроде все утилиты, обновляющие /etc/resolv.conf обучены вызывать
>> update_chrooted.
> Может быть стоит написать некий update_chrootd, который следил бы за
> всеми файлами, которые должны быть в чруте, и при их обновлении обновлял
> бы чрут?
>
Делать inotify на список файлов относящимся к chroot и по событию 
изменения делать update_chroot?

Re: [sisyphus] [devel] приключения resolv.conf в ALT

[Vladimir D. Seleznev]

On Fri, Apr 03, 2020 at 01:32:38PM +0300, Denis Medvedev wrote:
> 03.04.2020 13:28, Vladimir D. Seleznev пишет:
> > On Tue, Mar 31, 2020 at 10:05:17PM +0300, Alexey Shabalin wrote:
> >>> PS: следующим письмом попробую подробно описать наши кувыркания с resolv.conf.
> >>> дождитесь его, прежде чем отвечать :)
> >> 5) update_chrooted.
> >> Наши замечательные ALT особенности :)
> >> Множество сервисов и отдельных программ(например ping) запускаются в chroot.
> >> В этот chroot должны быть скопированы и библиотеки, и настройки для
> >> этих библиотек, в частности resolv.conf.
> >> Т.е. ping не использует /etc/resolv.conf, а использует
> >> /var/resolv/etc/resolv.conf.
> >> Нам очень важно держать в chroot'ах resolv.conf синхронным c с
> >> основной системой.
> >> Вроде все утилиты, обновляющие /etc/resolv.conf обучены вызывать
> >> update_chrooted.
> > Может быть стоит написать некий update_chrootd, который следил бы за
> > всеми файлами, которые должны быть в чруте, и при их обновлении обновлял
> > бы чрут?
> >
> Делать inotify на список файлов относящимся к chroot и по событию 
> изменения делать update_chroot?

Да.

-- 
   WBR,
   Vladimir D. Seleznev

Re: [sisyphus] [devel] приключения resolv.conf в ALT

[Vladimir D. Seleznev]

On Fri, Apr 03, 2020 at 01:37:41PM +0300, Vladimir D. Seleznev wrote:
> On Fri, Apr 03, 2020 at 01:32:38PM +0300, Denis Medvedev wrote:
> > 03.04.2020 13:28, Vladimir D. Seleznev пишет:
> > > On Tue, Mar 31, 2020 at 10:05:17PM +0300, Alexey Shabalin wrote:
> > >>> PS: следующим письмом попробую подробно описать наши кувыркания с resolv.conf.
> > >>> дождитесь его, прежде чем отвечать :)
> > >> 5) update_chrooted.
> > >> Наши замечательные ALT особенности :)
> > >> Множество сервисов и отдельных программ(например ping) запускаются в chroot.
> > >> В этот chroot должны быть скопированы и библиотеки, и настройки для
> > >> этих библиотек, в частности resolv.conf.
> > >> Т.е. ping не использует /etc/resolv.conf, а использует
> > >> /var/resolv/etc/resolv.conf.
> > >> Нам очень важно держать в chroot'ах resolv.conf синхронным c с
> > >> основной системой.
> > >> Вроде все утилиты, обновляющие /etc/resolv.conf обучены вызывать
> > >> update_chrooted.
> > > Может быть стоит написать некий update_chrootd, который следил бы за
> > > всеми файлами, которые должны быть в чруте, и при их обновлении обновлял
> > > бы чрут?
> > >
> > Делать inotify на список файлов относящимся к chroot и по событию 
> > изменения делать update_chroot?
> 
> Да.

Нет, при текущей архитектуре update_chrooted предложенное мной решение
невозможно. Для него надо с нуля придумывать всё решение. И если для
postfix'а нельзя декларативно указать все его конфиги, то боюсь в общем
случае это будет невозможно.

-- 
   WBR,
   Vladimir D. Seleznev

Re: [sisyphus] [devel] приключения resolv.conf в ALT

[Denis Medvedev]

03.04.2020 13:50, Vladimir D. Seleznev пишет:
> On Fri, Apr 03, 2020 at 01:37:41PM +0300, Vladimir D. Seleznev wrote:
>> On Fri, Apr 03, 2020 at 01:32:38PM +0300, Denis Medvedev wrote:
>>> 03.04.2020 13:28, Vladimir D. Seleznev пишет:
>>>> On Tue, Mar 31, 2020 at 10:05:17PM +0300, Alexey Shabalin wrote:
>>>>>> PS: следующим письмом попробую подробно описать наши кувыркания с resolv.conf.
>>>>>> дождитесь его, прежде чем отвечать :)
>>>>> 5) update_chrooted.
>>>>> Наши замечательные ALT особенности :)
>>>>> Множество сервисов и отдельных программ(например ping) запускаются в chroot.
>>>>> В этот chroot должны быть скопированы и библиотеки, и настройки для
>>>>> этих библиотек, в частности resolv.conf.
>>>>> Т.е. ping не использует /etc/resolv.conf, а использует
>>>>> /var/resolv/etc/resolv.conf.
>>>>> Нам очень важно держать в chroot'ах resolv.conf синхронным c с
>>>>> основной системой.
>>>>> Вроде все утилиты, обновляющие /etc/resolv.conf обучены вызывать
>>>>> update_chrooted.
>>>> Может быть стоит написать некий update_chrootd, который следил бы за
>>>> всеми файлами, которые должны быть в чруте, и при их обновлении обновлял
>>>> бы чрут?
>>>>
>>> Делать inotify на список файлов относящимся к chroot и по событию
>>> изменения делать update_chroot?
>> Да.
> Нет, при текущей архитектуре update_chrooted предложенное мной решение
> невозможно. Для него надо с нуля придумывать всё решение. И если для
> postfix'а нельзя декларативно указать все его конфиги, то боюсь в общем
> случае это будет невозможно.
>
Хотелось бы прописать политику о том, что любой пакет, желающий 
использовать chroot, должен иметь возможность работать БЕЗ chroot.

(легкую отключаемость этой IMHO mis-feature).

Re: [sisyphus] [devel] приключения resolv.conf в ALT

[Вадим Илларионов]

03.04.2020 18:51, Denis Medvedev пишет:
> Хотелось бы прописать политику о том, что любой пакет, желающий 
> использовать chroot, должен иметь возможность работать БЕЗ chroot.
>
> (легкую отключаемость этой IMHO mis-feature).


Всеми конечностями подпишусь / проголосую "за"!

Re: [sisyphus] [devel] приключения resolv.conf в ALT

[Вадим Илларионов]

03.04.2020 18:51, Denis Medvedev пишет:
> Хотелось бы прописать политику о том, что любой пакет, желающий 
> использовать chroot, должен иметь возможность работать БЕЗ chroot.
>
> (легкую отключаемость этой IMHO mis-feature).


Ибо на то есть контейнеры. :)