Bug 20410

Summary:	Доработать openresolv
Product:	Sisyphus	Reporter:	Mikhail Efremov <sem>
Component:	openresolv	Assignee:	Mikhail Efremov <sem>
Status:	ASSIGNED ---	QA Contact:	qa-sisyphus
Severity:	enhancement
Priority:	P3	CC:	aen, dd1email, evg, ldv, mike, pilot, sem
Version:	unstable
Hardware:	all
OS:	Linux

Description Mikhail Efremov 2009-06-11 04:47:16 MSD

Предыстория: https://bugzilla.altlinux.org/show_bug.cgi?id=20345

Т.к. #20345 закрыт, да и обсуждение давно вышло за рамки того, о чем был открыт баг, предлагаю продолжить тут.

> Поэтому конкуренция должна
> происходить не между серверами, а между группами серверов. Серверы внутри
> отдельно взятой группы должны рассматриваться как равнозначные и обеспечивающие
> доступ к одним и тем же данным. Это один из основных принципов работы DNS.
> Группа серверов, которая не выдержала конкуренции, не должна фигурировать в
> финальном файле вообще.

Я видимо сначала не правильно понял о чем тут речь. Предлагается просто подставлять содержимое resolv.conf от интерфейса, имеющего в данный момент наибольший приоритет, так?

> 1. Решать одну, самую главную задачу (конфигурация glibc resolver). Остальные
> задачи решаются в последнюю очередь, если вообще фигурируют к тому времени.

В случае, если конфигурировать glibc resolver не надо, т.к. предполагается, что в resolv.conf всегда стоит 127.0.0.1 (на основе тех же приоритетов), задача конфигурации локального DNS-сервера становится основной. И я до сих пор не понимая, зачем вообще надо противопоставлять эти 2 задачи и чем одна мешает другой.

> 2. Механизм выбора "победившей" версии resolv.conf сделать предельно
> формальным, компактным и предсказуемым. Унаследованные предпосылки в виде
> hardcoded списков interface_order и dynamic_order отбросить вообще. Серверов в
> /etc/resolvconf.conf не прописывать, им там не место.

Вот с этим готов согласиться. Как я себе это представляю я уже писал.

> 3. Назначенная администратором системы степень "хорошести"/"плохости" данных
> должна _всегда_ иметь решающее значение.

Это и сейчас так.

> Разница в том, чтобы пропускать через локально запущенный named не всё подряд и
> всегда, а только в нужные администратору периоды. И ещё в том, что этим
> "вечноживым" сервером может оказаться адрес не 127.0.0.1 и вообще не локального
> узла адрес. Не нужно без спросу заменять резолвер каждого процесса кэширующим
> сервером всего хоста.

С закрытием #20345 никто не мешает реализовать такую схему и сейчас. Но возможность сконфигурировать resolovconf так, чтобы в resolv,conf всегда первой (или единственной) строкой стояло 127.0.0.1 тоже должна быть. Используя resolvconf при этом для обновления конфигурации локального резолвера.

Comment 1 Denis Ovsienko 2009-06-12 13:48:24 MSD

Что же, с обновлённым фильтром в игре теперь участвуют все варианты resolv.conf. Насколько я успел сейчас выяснить, все они поступают на вход с умолчательной метрикой 0, которая также является самой высокой. Источники же, из которых они поступают --- etcnet и dhcpcd. И там, и там сейчас нет способа задать метрику административно. Попробую сейчас сделать следующее:
1. Обеспечить значения метрик по умолчанию.
2. Дать способ её изменить
3. Дать способ узнать текущее значение.
После этого будет ясно, работает ли механизм.

Comment 2 Mikhail Efremov 2009-06-12 15:01:23 MSD

(In reply to comment #1)
> Что же, с обновлённым фильтром в игре теперь участвуют все варианты
> resolv.conf. 

Мне не нравится способ, которым я сейчас это делаю. Но остальные варианты, которые мне приходили в голову нравятся мне еще меньше. Основная проблема - набор NAMESERVERS для libc и остальных подписчиков должен быть разный. Сейчас я просто отфильтровываю "лишние" в каждом подписчике, плюс сразу формирую DOMAINS без них, т.к. эта переменная используется только в подписчиках локальных резолверов для задания зон переадресации.

> Насколько я успел сейчас выяснить, все они поступают на вход с
> умолчательной метрикой 0, которая также является самой высокой. 

Все намного хуже: умолчательной метрики не существует. Интерфейсы, для которых использовалась метрика для добавлении автоматом имеют приоритет выше всех остальных, исключая интерфейсы, перечисленные в interface_order и dynamic_order.
В таком виде метрика сейчас практически бесполезна.

> Источники же,
> из которых они поступают --- etcnet и dhcpcd. И там, и там сейчас нет способа
> задать метрику административно.

Игроков может быть гораздо больше. Есть еще и NM, скрипты в ppp-common (отдельно от etcnet, т.к. ppp может подниматься не только используя etcnet), возможно сами звонилки вроде kppp, vpn-клиенты и наверняка кто-то еще. В конце концов можно просто руками добавлять.

Поэтому я думаю в первую очередь необходима возможность задать метрику в resolvconf.conf, но сначала надо, чтобы какое-либо значение метрики использовалось всегда и для всех интерфейсов. Хотя правильнее тут будет сказать не "интерфейс", а "имя источника", т.к. это может быть не обязательно имя интерфейса. NM так и добавляет resolv.conf от своего имени, да и я такое использую в alterator-openvpn-server. Так бывает удобнее, и ничего плохого в этом я не вижу, если иметь возможность задать приоритет по имени источника в resolvconf.conf. Такая возможность есть и сейчас, просто существующая схема не слишком очевидна.

Comment 3 Denis Ovsienko 2009-09-16 13:37:29 MSD

> задать метрику административно. Попробую сейчас сделать следующее:

[...]

Не сделал. Есть ли результаты опытов от других участников?

Comment 4 Mikhail Efremov 2009-09-16 14:41:16 MSD

(In reply to comment #3)
> Не сделал. Есть ли результаты опытов от других участников?

У меня, к сожалению, тоже нет. Мысли есть, но в код пока не воплотились. Идею я не забыл, думаю все-таки доберусь попробовать, но, скорее всего, не раньше чем через месяц. В общих чертах я вижу это так:

1. Ввести дополнительную переменную, в которой будет храниться значение дефолтной метрики. Не совсем ясно какое оно должно быть, openresolv позволяет использовать вплоть до 6-ти значных чисел для метрики. Думаю значения 100 точно хватит для достаточно гибкого управления метрикой.
2. В resolvconf.conf дать прописывать метрику как для конкретных источников, так и для групп. openresolv претендует на некоторую совместимость с Debian'овским resolvconf, я не думаю, что это стоит отрывать без крайней необходимости, хотя бы для того, чтобы предложить изменения в апстрим. Поэтому как минимум interface_order нужно оставить, но дать возможность задать метрику сразу для всей группы интерфейсов/источников, перечисленных в interface_order. Да и вообще создавать свои именнованные группы интерфейсов может быть удобно. Выглядеть это может например так:
metrics='interface_order/10 eth0/120 ppp1/50 my_interfaces_group/60'
где число после слэша - значение метрики.

При добавлении информации от источника, если не указано значение метрики непосредственно опцией -m, будет производится поиск среди значений в metrics, если там имени источника не найдется - будет использовано дефолтное значение метрики.
А в etcnet можно будет ввести переменную со значением метрики для интерфейса, устанавливать ее в options и, если эта переменная установлена, вызывать resolvconf с опцией -m.

Но пока это все мысли вслух.

Comment 5 Mikhail Efremov 2010-01-20 22:56:38 MSK

> Но пока это все мысли вслух.

Материализовались:
http://git.altlinux.org/people/sem/packages/?p=openresolv.git;a=commit;h=781c0d0aac87447eebe6162ed064f147e98dd699

Для групп интерфейсов, заканчивающихся на "*_order" значение метрики увеличивается на 1 для каждого следующего источника. Это в первую очередь для interface_order и dynamic_order, чтобы сохранялось такое же поведение как и раньше.
Значение по умолчанию default_metric и метрик для {interface,dynamic}_order задал пока от балды, может стоит поставить другие значения.