Bug 20410 - Доработать openresolv
: Доработать openresolv
Status: ASSIGNED
: Sisyphus
(All bugs in Sisyphus/openresolv)
: unstable
: all Linux
: P3 enhancement
Assigned To:
:
:
:
:
:
  Show dependency tree
 
Reported: 2009-06-11 04:47 by
Modified: 2010-01-20 22:56 (History)


Attachments


Note

You need to log in before you can comment on or make changes to this bug.


Description From 2009-06-11 04:47:16
Предыстория: 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 From 2009-06-12 13:48:24 -------
Что же, с обновлённым фильтром в игре теперь участвуют все варианты
resolv.conf. Насколько я успел сейчас выяснить, все они поступают на вход с
умолчательной метрикой 0, которая также является самой высокой. Источники же,
из которых они поступают --- etcnet и dhcpcd. И там, и там сейчас нет способа
задать метрику административно. Попробую сейчас сделать следующее:
1. Обеспечить значения метрик по умолчанию.
2. Дать способ её изменить
3. Дать способ узнать текущее значение.
После этого будет ясно, работает ли механизм.
------- Comment #2 From 2009-06-12 15:01:23 -------
(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 From 2009-09-16 13:37:29 -------
> задать метрику административно. Попробую сейчас сделать следующее:

[...]

Не сделал. Есть ли результаты опытов от других участников?
------- Comment #4 From 2009-09-16 14:41:16 -------
(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 From 2010-01-20 22:56:38 -------
> Но пока это все мысли вслух.

Материализовались:
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
задал пока от балды, может стоит поставить другие значения.