[Desktop] Зачем нужен dnsmasq?

[Stanislav Ievlev]

On Mon, Feb 09, 2009 at 08:40:36PM +0300, Alexei V. Mezin wrote:
> Andrey Rahmatullin пишет:
> >On Sun, Feb 08, 2009 at 12:56:47PM +0300, Anatol B. Bazyukin wrote:
> >>http://lists.altlinux.org/pipermail/devel/2008-December/164009.html ?
> >Вот, оно.
> 
> Ну так и что? Поругались и забили в итоге?
Если виноват был NetworkManager, то наверное надо багу на него и повесить
и соотв. приоритет поставить. Никто кроме мантейнера этого пакета
не объяснит зачем такая зависимость.
> 
> Только что проверил, как ведет себя 
> Альтератор в смысле настройки ДНС для 
> сетевого интерфейса ethernet. Ведет он себя 
> очень странно и непонятно.
> 
> Проверял на VirtualBox-NAT. При установке 
> системы указал DHCP, все остальное по 
> умолчанию. После установке запустил acc, в 
> настройках eth в поле "DNS servers" прописано 
> 127.0.0.1, что вобщем-то соотвествует идее 
> наличия dnsmasq.
> 
> Однако! Пытаюсь ввести альтернативный 
> ДНС (к примеру 193.125.143.173), система не 
> сопротивляется. Жму "применить", 
> задумывается, в логах видно, что 
> рестартует сеть, что-то там обсуждает с 
> DHCP-сервером, и... в поле "DNS servers" повяляется 
> 10.0.2.3 (адрес, которые выдает DHCP-сервер 
> ВиртуалБокса).
> 
> Вешать багу на Альтератор? Ибо такое 
> поведение явный баг.
Не баг,но недофича. То есть ведёт-то он себя естественно, но галки для
поправки поведения для такой вот странной ситуации когда человеку дают
dns-сервер, а он его не хочет.

Тут вот какое дело.

Раньше галочка, которая рулила настройками DHCP_ARGS давалось большой
ценой, частично из-за того что она была в естественом для пользователя
месте но противоестественном (как это обычно бывает) для etcnet - то бишь
это было общее свойство, но не свойство конкретного интерфейса.

Потом в какой-то момент по мере реализации разных запросов пользователей
типа hardware bindings место на экране закончилось и галка исчезла.

Сейчас я наблюдаю ещё более печальную картину:
* В etcnet как не было общего способа управлением подобным поведением dhcp-клиента так и нет.
* В dhcpcd 4.0.x появился конфиг-файл не менее странненький чем у dhclient и
  совершенно изменился формат опций. Теперь, если я правильно понял,
  вместо того чтобы просто сказать "не трогай resolv.conf", надо говорить
  "не исполняй хук такой-то".
* dhclient на эту тему всегда был невменямым с точки зрения настройки.

В общем багу повесить можно, доберусь - постараюсь вернуть прохакивание DHCP_ARGS, заточенное 
под dhcpcd 4.0.x и старше. Но кто знает надолго ли хватит. Нынешний
гентушный upstream dhcpcd кажется решил сделать второй network-manager и
если они и раньше-то ломали вдоль и поперёк опции когда-то простой
утилиты, то вряд ли остановятся и потом.