Bug 24637

Summary:	При удалении "поинтерфейсного" resolv.conf не вызывается resolvconf -d
Product:	Sisyphus	Reporter:	Mikhail Efremov <sem>
Component:	etcnet	Assignee:	Mikhail Efremov <sem>
Status:	CLOSED FIXED	QA Contact:	qa-sisyphus
Severity:	normal
Priority:	P3	CC:	dd1email, ldv, mike, rider, sem, shaba, vseleznv
Version:	unstable
Hardware:	all
OS:	Linux

Description Mikhail Efremov 2010-11-24 18:49:39 MSK

По мотивам давнего обсуждения в https://bugzilla.altlinux.org/show_bug.cgi?id=19152.
Надо бы все-таки при опускании интерфейса запускать resolvconf -d в любом случае, а не только при наличии  "поинтерфейсного" resolv.conf.
Правда, при отсутствии "поинтерфейсного" resolv.conf нельзя быть уверенным, что ns были добавлены ранее именно с помощью etcnet. Но, думаю, это не важно, т.к. если кто-то добавлял ns с именем источника, совпадающим с именем интерфейса, то можно с большой вероятностью предположить, что эти записи не будут иметь смысла при опущенном интерфейсе. Иначе лучше использовать другое имя.
Изменение, собственно, тривиально:
http://git.altlinux.org/people/sem/packages/etcnet.git?p=etcnet.git;a=commitdiff;h=79e8d08a8bdc448f65503c33f3b57db63b9bd58f
Для подавления сообщения об ошибке можно было бы использовать -f, но Debian'овский resolvconf не имеет такой опции. Думаю, лучше не завязываться в etcnet именно на openresolv без необходимости.

Comment 1 Michael Shigorin 2011-09-09 16:31:29 MSK

На днях опять наткнулся, подключив в кои-то веки дома гигабитным шнурком, а потом в офисе опять соскочив на wifi.

Comment 2 Mikhail Efremov 2011-09-09 16:54:49 MSK

> На днях опять наткнулся, подключив в кои-то веки дома гигабитным шнурком, а
> потом в офисе опять соскочив на wifi.

А это точно та же проблема? Здесь речь идет о том, что если в /etc/net/ifaces/<interface>/ лежит некий resolv.conf, то после его удаления и последующего ifdown && ifup, ns, добавленные из этого resolv.conf все равно остаются в /etc/resolv.conf. Т.к. не было вызова resolvconf -d.

Comment 3 Michael Shigorin 2011-09-09 18:44:32 MSK

Возможно -- зависит от того, что и когда удаляет интерфейсный resolv.conf.

Тут было так:
- дома болтается wlan0 и поднят eth0;
- засыпаем (выполняется rmmod iwl3945);
- на конторе просыпаемся, поднимаем wlan0;
- удивляемся задумчивому резолвингу и обнаруживаем в /etc/resolv.conf
  фрагменты домашней конфигурации;
- отыскиваем и сносим /var/run/resolvconf/interfaces/eth0

Comment 4 Mikhail Efremov 2011-09-09 19:16:18 MSK

(В ответ на комментарий №3)
> Возможно -- зависит от того, что и когда удаляет интерфейсный resolv.conf.

Его никто не удаляет. Если только альтератор при изменении настроек интерфейса.

> Тут было так:
> - дома болтается wlan0 и поднят eth0;
> - засыпаем (выполняется rmmod iwl3945);
> - на конторе просыпаемся, поднимаем wlan0;
> - удивляемся задумчивому резолвингу и обнаруживаем в /etc/resolv.conf
>   фрагменты домашней конфигурации;

Здесь больше интересно какая конфигурация, статика или dhcp. В случае статической конфигурации resolvconf -d выполняет etcnet при наличии /etc/net/ifaces/<interface>/resolv.conf, в случае dhcp - dhcpcd в своих хуках.

> - отыскиваем и сносим /var/run/resolvconf/interfaces/eth0

Цивилизованный путь - resolvconf -d eth0. При этом и /etc/resolv.conf будет перегенерен.

В общем это другая проблема скорее всего, пошли в рассылки что-ли.

Comment 5 Michael Shigorin 2011-09-09 20:01:43 MSK

Виноват; в обоих случаях dhcp; согласен.

Comment 6 Repository Robot 2012-11-06 19:43:10 MSK

etcnet-0.9.10-alt7 -> sisyphus:

* Tue Nov 06 2012 Sergey Bolshakov <sbolshakov@altlinux> 0.9.10-alt7
- CONFIG_WIRELESS and USE_IFPLUGD options are mutually exclusive now
- do not rely on /sys/class/net/<iface>/wireless anymore (closes: #27797)
- added per-iface 'disable_ipv6' sysctl shortcut (closes: #27933)
- always use 'resolvconf -d' during ifdown (closes: #24637)