Предыстория: 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 при этом для обновления конфигурации локального резолвера.
Что же, с обновлённым фильтром в игре теперь участвуют все варианты resolv.conf. Насколько я успел сейчас выяснить, все они поступают на вход с умолчательной метрикой 0, которая также является самой высокой. Источники же, из которых они поступают --- etcnet и dhcpcd. И там, и там сейчас нет способа задать метрику административно. Попробую сейчас сделать следующее: 1. Обеспечить значения метрик по умолчанию. 2. Дать способ её изменить 3. Дать способ узнать текущее значение. После этого будет ясно, работает ли механизм.
(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. Такая возможность есть и сейчас, просто существующая схема не слишком очевидна.
> задать метрику административно. Попробую сейчас сделать следующее: [...] Не сделал. Есть ли результаты опытов от других участников?
(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. Но пока это все мысли вслух.
> Но пока это все мысли вслух. Материализовались: 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 задал пока от балды, может стоит поставить другие значения.
