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