Bug 4249 - stuck "# ppp temp entry" in /etc/resolv.conf
: stuck "# ppp temp entry" in /etc/resolv.conf
Status: CLOSED FIXED
: Sisyphus
(All bugs in Sisyphus/ppp-common)
: unstable
: all Linux
: P2 critical
Assigned To:
:
:
:
:
: 3459 7079 13773
  Show dependency tree
 
Reported: 2004-05-28 14:29 by
Modified: 2008-01-10 18:43 (History)


Attachments


Note

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


Description From 2004-05-28 14:29:31
После kppp, который создает в /etc/resolve.conf "#kppp temp entry" 
остаются записи "# ppp temp entry", kppp их соответственно убирать не должен, 
т.к. убирает только свои "#kppp temp entry" 

Как лучше сделать? 
kppp научить убирать или в /etc/ppp/ip-up сделать то-то типа 
-if grep -iqs '#.*ppp temp entry' /etc/resolv.conf; then 
+if grep -iqs '.*# ppp temp entry' /etc/resolv.conf; then
------- Comment #1 From 2004-05-28 15:31:49 -------
И к чему это приводит? Дайте сценарий для просмотра непорядка.
------- Comment #2 From 2004-05-28 17:31:06 -------
http://lists.altlinux.ru/pipermail/sisyphus/2004-May/041596.html 
 
Сценарий простой: 
присоединиться при помощи KPPP 
У него должна быть включены опции для автоматического определения DNS 
и для закрытия доступа к существующим DNS на время соединения. 
После завершения KPPP в /etc/resolv.conf должны остаться лишние строки. 
 
------- Comment #3 From 2004-05-29 01:51:53 -------
Так ведь есть же в /etc/ppp/ip-down строки 
subst "/nameserver $DNS1 $PPP_TEMP_ENTRY/d" /etc/resolv.conf 
subst "/nameserver $DNS2 $PPP_TEMP_ENTRY/d" /etc/resolv.conf 
 
У меня всё нормально удаляется. 
------- Comment #4 From 2004-05-29 18:57:04 -------
Не могу воспроизвести. В sisyphus@ отправлен запрос на доп. информацию.
------- Comment #5 From 2004-05-31 09:36:34 -------
> Так ведь есть же в /etc/ppp/ip-down строки 
у меня нет :-( 
net-scripts-0.4.7-alt1 
------- Comment #6 From 2004-05-31 15:03:03 -------
Господа, дайте мне пожалуйста в почту ls -lR /etc/sysconfig/network-scripts
/etc/ppp
------- Comment #7 From 2004-05-31 16:57:32 -------
ip-down у меня без таких строк. net-scripts-0.4.8-alt1
------- Comment #8 From 2004-05-31 19:42:25 -------
(In reply to comment #7) 
> ip-down у меня без таких строк. net-scripts-0.4.8-alt1 
 
У меня еще пока не 0.4.8. Сейчас проапдейчусь... 
 
------- Comment #9 From 2004-05-31 20:21:42 -------
Вот чёрт. Скрипт /etc/ppp/ip-down оказался у меня подредактированным. Кем и
когда уже не помню. Не заметил этого по той причине, что при обновлении
net-scripts rpm почему-то молчит, что некоторые файлы не были перезаписаны
(.rpmnew тоже не появились).

В ip-down тут после вызова ifdown-post написано буквально следующее:

# for dynamic DNS support with gnome-ppp and kppp and draknet (adsl)
if grep -iqs '#.*ppp temp entry' /etc/resolv.conf; then
    PPP_TEMP_ENTRY=`grep '#.*ppp temp entry' /etc/resolv.conf | \
       tail -1 | sed 's/.*ppp temp entry/# ppp temp entry/' `
else
    unset PPP_TEMP_ENTRY
fi
if [ -n "$PPP_TEMP_ENTRY" ]; then
    [ -n "$DNS1" ] && \
    subst "/nameserver $DNS1 $PPP_TEMP_ENTRY/d" /etc/resolv.conf
    [ -n "$DNS2" ] && \
    subst "/nameserver $DNS2 $PPP_TEMP_ENTRY/d" /etc/resolv.conf
fi

Уж не знаю, каково должно быть правильное поведение в отношении PPP_TEMP_ENTRY,
но, на мой взгляд, удалять временные строки ip-down просто обязан, раз ip-up их
 добавляет. Возможно, разумнее было бы зафиксировать
PPP_TEMP_ENTRY="# ppp temp entry"
и удалять все строки, как написано выше, без дополнительных проверок. Правда и
в
ip-up мне тоже не очень ясна логика таких проверок и возни с PPP_TEMP_ENTRY.
------- Comment #10 From 2004-05-31 20:36:58 -------
 (In reply to comment #2) 
> http://lists.altlinux.ru/pipermail/sisyphus/2004-May/041596.html  
>   
> Сценарий простой:  
> присоединиться при помощи KPPP  
> У него должна быть включены опции для автоматического определения DNS  
> и для закрытия доступа к существующим DNS на время соединения.  
> После завершения KPPP в /etc/resolv.conf должны остаться лишние строки.  
 
я Денису в личном письме риторический вопрос задавал уже вчера, озвучу  
тут. Зачем, вообще, нужно, чтобы kppp что-то делал с resolve.conf, если  
он, все равно, вызывает pppd, у которого есть свои способы отработать  
ключ usepeerdns ? Мне кажется, что это лишнее совершенно.  
  
net-scripts проапдейтил, проблема на месте.   
 
------- Comment #11 From 2004-06-01 00:12:55 -------
По полученным листингам я теперь буду думать.
------- Comment #12 From 2004-06-01 12:01:38 -------
Может просто я в kppp сменю  
"#kppp temp entry" 
на какой-нибудь 
"# temp entry of kppp" ? 
------- Comment #13 From 2004-06-01 12:24:31 -------
А смысл? Так их одно регулярное выражение подхватывает, а так два нужно будет.
Дайте поэкспериментировать денёк.
------- Comment #14 From 2004-06-01 14:10:53 -------
(In reply to comment #12) 
 
> Может просто я в kppp сменю   
> "#kppp temp entry"  
> на какой-нибудь  
> "# temp entry of kppp" ?  
 
Все-таки, зачем оно, вообще, нужно ? Почему не убрать совсем прописывание DNS ? 
Пусть этим pppd занимается. 
 
------- Comment #15 From 2004-06-01 14:44:31 -------
Я кажется нашел, с чем это может быть связано. 
D kppp есть функция addperrdns, которая из /etc/ppp/resolv.conf 
копирует все строки, добивая в конце каждой "#kppp temp entry" 
------- Comment #16 From 2004-06-01 14:48:13 -------
> Почему не убрать совсем прописывание DNS ?  
> Пусть этим pppd занимается. 
А у него есть для этого gui-настройка, 
к тому же работающая из-под пользователя? 
 
------- Comment #17 From 2004-06-01 15:05:25 -------
(In reply to comment #14)
[...]
> Все-таки, зачем оно, вообще, нужно ? Почему не убрать совсем прописывание DNS ? 
> Пусть этим pppd занимается. 
У меня он этим не занимается, если запущен из-под kppp. Пожалуйста ничего пока в
kppp не меняйте.
------- Comment #18 From 2004-06-01 15:40:50 -------
> У меня он этим не занимается, если запущен из-под kppp. 
Возможно это связано с /etc/ppp/resolv.conf 
Но у меня здесь его нет, прикрепите кто-нибудь, я не помню, что там конкретно. 

> Пожалуйста ничего пока в kppp не меняйте. 
Не буду 
------- Comment #19 From 2004-06-01 15:48:15 -------
> Возможно это связано с /etc/ppp/resolv.conf  
> Но у меня здесь его нет, прикрепите кто-нибудь, я не помню, что там 
конкретно.  
 
---/etc/ppp/resolv.conf 
nameserver 10.1.1.1 
nameserver 10.1.2.1 
--- 
 
только две строчки 
------- Comment #20 From 2004-06-02 01:03:20 -------
Господа, у которых /etc/ppp/resolv.conf в наличии, удалите rp-pppoe-client или
/etc/ppp/resolv.conf, пока не исправится
https://bugzilla.altlinux.org/show_bug.cgi?id=4276
------- Comment #21 From 2004-06-02 01:42:57 -------
Причина мистического появления "# ppp temp entry" выяснена. Race condition.
Если
kppp успевает поместить свои "# kppp temp entry" до запуска /etc/ppp/ip-up, то
ip-up их добросовестно отдублирует, предварительно сохранив файл со строчками
kppp как /etc/resolv.conf.save Если ip-up запускается раньше, то он не трогает
/etc/resolv.conf. Проверяется вставкой sleep в начало ip-up.
Как видно, на моей машине сейчас первым отрабатывает ip-up, почему я этих строк
и не видел.
При опускании интерфейса ip-down возвращает назад сохранённый resolv.conf со
строчками kppp.
Возможны отклонения, но суть проблемы ясна. Я просто уже замучился дёргать
туда-сюда ppp0.
(In reply to comment #15)
> Я кажется нашел, с чем это может быть связано. 
> D kppp есть функция addperrdns, которая из /etc/ppp/resolv.conf 
> копирует все строки, добивая в конце каждой "#kppp temp entry" 
Такое есть. kppp пытается заменять собой ip-up в этом отношении, но действуют
они (kppp и скрипты ppp) вразнобой, причём непредсказуемо.

Решений я вижу несколько: править kppp, добавить sleep в ip-up/ip-down для
меньшей вероятности race condition, удалять всё вида "#.*ppp temp entry" в
ifdown-post. Можно ещё попробовать в ip-up/ip-down выяснять родителя своего
родителя и если это kppp/*ppp (а звонилок у нас хватает), то обрабатывать это
как отдельный случай.
Есть пожелания или соображения?
------- Comment #22 From 2004-06-02 13:29:47 -------
Мне кажется, что Вы несколько погорячились с предложением удалить
rp-pppoe-client. Как люди будут выходит в инет? 
------- Comment #23 From 2004-06-02 13:39:52 -------
Тогда давайте чиниться одновременно.
------- Comment #24 From 2004-06-02 22:26:27 -------
Кто-нибудь, скажите !! ЗАЧЕМ ?!?!  
 
Зачем лазить в resolve.conf кому-то, кроме pppd ?  
Это нужно только в одном случае - если DNS задаются 
в ручную и usepeerdns не используется при запуске 
pppd. 
 
------- Comment #25 From 2004-06-02 22:42:41 -------
Давайте внесём ясность: pppd сам туда не лазит, он только сохраняет фрагмент,
подлежащий вставке, и запускает скрипт.
------- Comment #26 From 2004-06-03 01:01:22 -------
(In reply to comment #25) 
 
Ну, я это и имел ввиду. Зачем дублировать то, что уже сдлано, а потом еще и 
бороться с результатом этого дублирования ? Единственный момент, это придется 
во всех используемых звонилках отрывать, если до конца идти...  
 
------- Comment #27 From 2004-06-03 07:49:45 -------
Если все звонилки делятся на те, которые могут сами вставить содержимое
/etc/ppp/resolv.conf в /etc/resolv.conf и на те, которые вообще не трогают
/etc/resolv.conf, тогда я предлагаю следующее: ввести флаг вида KEEP_RESOLVCONF
где-нибудь в /etc/sysconfig/network, который будет определять, что ip-up и
ip-down не будут трогать /etc/resolv.conf.
Так все должны помириться.
------- Comment #28 From 2004-06-03 11:26:58 -------
(In reply to comment #24) 
> Кто-нибудь, скажите !! ЗАЧЕМ ?!?!   
>   
> Зачем лазить в resolve.conf кому-то, кроме pppd ?   
> Это нужно только в одном случае - если DNS задаются  
> в ручную 
прямо из kppp 
 
> и usepeerdns не используется при запуске  
> pppd.  
kppp не лазит, если не включена(это по-умолчанию) соответствующая опция в его 
настройках 
 
------- Comment #29 From 2004-06-03 11:30:40 -------
(In reply to comment #21) 
> удалять всё вида "#.*ppp temp entry" в ifdown-post 
А чем это может быть плохо? 
 
------- Comment #30 From 2004-06-03 11:33:44 -------
> А чем это может быть плохо? 
Сейчас не могу представить, чем. Но вдруг?
------- Comment #31 From 2004-06-03 11:34:38 -------
 (In reply to comment #26) 
> Ну, я это и имел ввиду. Зачем дублировать то, что уже сдлано 
Это понятие растяжимое 
KPPP не дублирует GUI, которого нет в ppp/net-scripts 
 
------- Comment #32 From 2004-06-03 11:35:38 -------
(In reply to comment #30) 
> > А чем это может быть плохо?  
> Сейчас не могу представить, чем. Но вдруг? 
Ща в devel@ спрошу  
 
 
------- Comment #33 From 2004-06-03 16:05:49 -------
(In reply to comment #28) 
 
> > и usepeerdns не используется при запуске   
> > pppd.   
 
> kppp не лазит, если не включена(это по-умолчанию) соответствующая опция в его  
> настройках  
 
Что за опция ? Не видел. Или речь про опцию автоопределения DNS ? Ну, так я 
понимаю, что она не только бесполезную правку resolve.conf инициирует, но и 
весьма полезный параметр usepeerdns в строку запуска pppd добавляет. Так ведь ? 
 
------- Comment #34 From 2004-06-03 17:35:29 -------
Если не использовать usepeerdns, то NS'ы в систему никак не попадут. Значит,
нужно использовать usepeerdns. Соответственно тогда NSы не только попадают в
/etc/ppp/resolv.conf, но и втягиваются в /etc/resolv.conf силами ip-up.
Соответственно звонилка тогда лазить в /etc/resolv.conf не должна. Если кто-то
может отучить от этого kppp и все остальные звонилки, пожалуйста. (Кстати, как
много их?).
Если же нет, то я ввожу флаг и делаю как планировал. Поведение по умолчанию от
старого отличаться не будет.
------- Comment #35 From 2004-06-03 22:40:32 -------
Противопоказание найдено: 
Mikhail Yakshin <greycat@altlinux>: 
> Э... Стоп... А если ppp-интерфейсов несколько?.. То что, при опускании  
> одного из них все их entries будут убиваться?.. 
 
------- Comment #36 From 2004-06-03 22:52:52 -------
(In reply to comment #28) 
  
> kppp не лазит, если не включена(это по-умолчанию) соответствующая опция в 
его  
> настройках  
Обманул, лазит он, если вкючено (это по-умолчанию) автоматическое определение 
dns, но не создает строк с "#entry disabled by kppp", если выключена(это 
по-умолчанию) опция закрытия доступа к существующим DNS на время соединения. 
 
Про такие строки ip-up не знает. 
 
------- Comment #37 From 2004-06-03 23:15:09 -------
(In reply to comment #35)
> > Э... Стоп... А если ppp-интерфейсов несколько?.. То что, при опускании  
> > одного из них все их entries будут убиваться?.. 
Если имеется в виду машина с одним ppp-интерфейсом с выдачей DNS-серверов и
одним или более более простых, то да. Предлагаете перескочить на #
ppp{0|1|2|3...} temp entry и более сложную логику?
------- Comment #38 From 2004-06-03 23:17:12 -------
(In reply to comment #36)
[...]
> Обманул, лазит он, если вкючено (это по-умолчанию) автоматическое определение 
> dns, но не создает строк с "#entry disabled by kppp", если выключена(это 
> по-умолчанию) опция закрытия доступа к существующим DNS на время соединения. 
Не создаёт. Автоопредление + закрытие были включены.

> Про такие строки ip-up не знает. 
Не знает, поэтому пропускает.
------- Comment #39 From 2004-06-04 10:42:52 -------
(In reply to comment #37) 
 
> Если имеется в виду машина с одним ppp-интерфейсом с выдачей DNS-серверов и 
> одним или более более простых, то да. Предлагаете перескочить на # 
> ppp{0|1|2|3...} temp entry и более сложную логику? 
 
Зачем в системе толпа работающих DNS ? Мне кажется, даже если PPP интерфейсов 
несколько, использовать usepeerdns более, чем на одном пире идея достаточно 
непонятная. Уж лучше тогда их руками все прописать... В общем, не думаю, что 
стоит усложнять и стоит просто документировать необходимость использования 
usepeerdns не более, чем у одного pppd. И, вообще, в этом случае надо 
кэширующий DNS поднимать локально и уже его конфигурить. 
 
------- Comment #40 From 2004-06-04 11:08:00 -------
Да. На текущий момент ограничимся предположением, что usepeerdns автоматически
подразумевает не более одного ppp-интерфейса.
И к понедельнику я постараюсь предоставить наконец-то решение.
------- Comment #41 From 2004-06-13 16:08:50 -------
1. kppp не закрывает существующие nameserver
2. Возможно, это и есть решение исходной проблемы: добавьте в
/etc/sysconfig/network строку RESOLV_MODS=no, скрипты после этого не должны
менять resolv.conf.
------- Comment #42 From 2004-06-15 12:03:18 -------
Если никто не напишет обратного, то я считаю, что проблема решена.
------- Comment #43 From 2004-06-15 12:09:37 -------
(In reply to comment #42) 
> Если никто не напишет обратного, то я считаю, что проблема решена. 
 
Т.е. по-умолчанию она остается? 
------- Comment #44 From 2004-06-15 12:25:11 -------
Например, у меня по умолчанию сейчас не проявляется, хотя когда-то проявлялось.
Предлагаю отметить в документации, что есть такая переменная и если
конфигурацией DNS занимается только kppp, то её нужно установить.
------- Comment #45 From 2004-06-15 13:02:42 -------
(In reply to comment #44) 
> Например, у меня по умолчанию сейчас не проявляется, 
Это хорошо. 
А вообще я бы и в kppp какой-нибудь workaround сделал, 
чтоб пользователям kppp не нужно было ничего настраивать в связи с этим. 
Только уже запутался, что нужно. 
Убирать все "#.*ppp temp entry" а не только "#kppp temp entry" ? 
 
------- Comment #46 From 2004-06-15 13:23:30 -------
Давайте kppp не трогать, иначе будет полная неразбериха.
------- Comment #47 From 2004-06-15 14:03:26 -------
(In reply to comment #46) 
> Давайте kppp не трогать, иначе будет полная неразбериха. 
Ok 
------- Comment #48 From 2004-06-17 00:19:18 -------
Что-то у меня RESOLV_MODS=no эффекта не дает... 
 
 
------- Comment #49 From 2004-06-17 10:23:28 -------
> Что-то у меня RESOLV_MODS=no эффекта не дает... 
То есть добавляется каждый раз по паре "# ppp temp entry"? Не верю.
------- Comment #50 From 2004-06-17 21:17:34 -------
Я всё понял. Ждите новых net-scripts.
<Pilot> а решение будет таким: RESOLV_MODS должен обрабатываться не только в
ifup-post
<Pilot> и вдобавок нужно оставить одно место, в котором правится resolv.conf, а
то так два раза получается
------- Comment #51 From 2004-06-24 21:55:17 -------
Пошло в net-scripts-0.4.9. Ставлю дубликат, но на самом деле RESOLVED FIXED,
попрошу взять в Master 2.4.

*** This bug has been marked as a duplicate of 2589 ***
------- Comment #52 From 2004-06-27 12:39:19 -------
Да, перестали дубли появляться.  
------- Comment #53 From 2004-07-02 20:10:39 -------
клево :-) 
------- Comment #54 From 2004-07-08 12:01:52 -------
*** Bug 4276 has been marked as a duplicate of this bug. ***
------- Comment #55 From 2004-07-17 06:30:50 -------
А кто сейчас убирает из /etc/resolv.conf строки nameserver, добавленные
/etc/ppp/ip-up? Они у меня почему-то остаются.
------- Comment #56 From 2004-08-04 16:01:42 -------
(In reply to comment #55)
> А кто сейчас убирает из /etc/resolv.conf строки nameserver, добавленные
> /etc/ppp/ip-up? Они у меня почему-то остаются.
Опишите пожалуйста конфигурацию.
------- Comment #57 From 2004-08-06 03:51:16 -------
Установлен net-scripts-0.4.9.1-alt1. В /etc/sysconfig/network RESOLV_MODS=yes.
Звоню wvdial'ом. После поключения в /etc/resolv.conf справедливо появляются две
строки
nameserver xxx.xxx.xxx.xxx # ppp temp entry
После отключения эти строки остаются и впоследствии только плодятся.
Может у меня чего не так? Ткните, какой скрипт их должен удалять?
------- Comment #58 From 2004-08-11 14:59:40 -------
Я понял причину.
------- Comment #59 From 2004-08-17 20:08:01 -------
Кстати, ifcfg-ppp0 и chat-ppp0 в наличии?
------- Comment #60 From 2004-08-20 12:34:26 -------
Господа, ставлю block на master, ибо после дня использования kppp я свой
resolv.conf потерял ;-(

Система - самый последний Sisyphus. Т.е. - в master эта ошибка наблюдается.
------- Comment #61 From 2004-08-20 14:04:41 -------
Подтвердить/опровергнуть не могу, я после первого успешного исправления 
net-scripts дома не апдейтил. Сегодня проапдейчуть по такому случаю. Для 
статистики... 
------- Comment #62 From 2004-08-20 15:33:05 -------
(In reply to comment #60)
> Господа, ставлю block на master, ибо после дня использования kppp я свой
> resolv.conf потерял ;-(
Что там было и что осталось? Наличие ifcfg-ppp0?

> Система - самый последний Sisyphus. Т.е. - в master эта ошибка наблюдается.
0.4.9.1, другими словами.
------- Comment #63 From 2004-08-22 18:05:51 -------
net-scripts-0.4.9.1-alt1 
За вчера и сегодня особых проблем не замечено. resolve.conf такой: 
-------------------- 
search localdomain xxxxxxx.xx yyyyyy.yy 
 
nameserver 127.0.0.1 
nameserver xxx.xxx.xxx.xxx 
nameserver xxx.xxx.xxx.xxx 
 
# ppp temp entry 
-------------------- 
 
Единственное замечание - #kppp temp entry не удалились при 
выключении без предварительного рассоединения. Следующий 
дозвон добавил еще два, но удалились потом все четыре. Вообще, 
проблему это может породить, если используется несколько точек 
доступа, которые отдают кэширующие DNS, которые не предназначены 
для доступа с любой точки сети. 
 
------- Comment #64 From 2004-08-23 14:45:16 -------
(In reply to comment #59)
> Кстати, ifcfg-ppp0 и chat-ppp0 в наличии?

Нет, отсутствуют.
------- Comment #65 From 2004-08-30 12:52:05 -------
(In reply to comment #60)
Проблема решается, если обозначить 'RESOLV_MODS=no' в /etc/sysconfig/network?
------- Comment #66 From 2004-12-13 14:24:06 -------
Интересно, новый баг завести, или здесь писать... 
В общем, теперь из resolv.conf просто каша получается. 

До запуска kppp: 
===== 
search localdomain domain1.ru domain2.ru 

nameserver 127.0.0.1 
nameserver xxx.xxx.xxx.xxx 
nameserver yyy.yyy.yyy.yyy 

# ppp temp entry 
===== 

после запуска: 
===== 
nameserver xxx.xxx.xxx.xxx 
nameserver yyy.yyy.yyy.yyy 
nameserver xxx.xxx.xxx.xxx        #kppp temp entry 
nameserver yyy.yyy.yyy.yyy        #kppp temp entry 
nameserver xxx.xxx.xxx.xxx        #kppp temp entry        #kppp temp entry 
nameserv 
===== 

Ну и после завершения остаются только первые  
две строчки. Ладно nameserver, но по что search 
обидели ? Без него плохо совсем. ;-) 

net-scripts-0.5.0-alt1 
------- Comment #67 From 2004-12-14 11:35:00 -------
(In reply to comment #66) 
> В общем, теперь из resolv.conf просто каша получается.  
Видимо из-за того, что /etc/ppp/resolv.conf - ссылка на /etc/resolv.conf 
 
 
------- Comment #68 From 2004-12-14 13:25:36 -------
(In reply to comment #67) 
 
> Видимо из-за того, что /etc/ppp/resolv.conf - ссылка на /etc/resolv.conf  
 
1. Да, действительно. А почему бы ее не удалять ? Или это проблема предыдущего 
пакета ? 
 
2. Теперь все вернулось совсем в исходное состояние. Добавляется  
nameserver xxx.xxx.xxx.xxx # ppp temp entry 
nameserver yyy.yyy.yyy.yyy # ppp temp entry 
nameserver xxx.xxx.xxx.xxx        #kppp temp entry 
nameserver yyy.yyy.yyy.yyy        #kppp temp entry 
 
А сносится только  
nameserver xxx.xxx.xxx.xxx        #kppp temp entry 
nameserver yyy.yyy.yyy.yyy        #kppp temp entry 
 
 
 
 
 
 
 
------- Comment #69 From 2004-12-14 13:53:42 -------
(In reply to comment #68) 
> А почему бы ее не удалять ? 
Меня больше волнует, почему это ссылка, а не файл. 
------- Comment #70 From 2004-12-14 16:16:17 -------
> Меня больше волнует, почему это ссылка, а не файл.  

Был поставлен Master 2.4 DVD, затем был dist-upgrade в Сизиф. Больше ничего не 
делалось, на сколько я помню.  

------- Comment #71 From 2004-12-14 16:39:29 -------
(In reply to comment #70) 
> Был поставлен Master 2.4 DVD, затем был dist-upgrade в Сизиф. Больше ничего 
не  
> делалось, на сколько я помню.   
У меня без Сизифа на М2.4 ссылка 
------- Comment #72 From 2004-12-14 16:50:06 -------
Чтобы понять, откуда взялся симлинк /etc/ppp/resolv.conf, смотрите комментарий
#20 этой эпической саги и ссылку, в нём приведённую.
------- Comment #73 From 2005-06-14 12:34:27 -------
все еще воспроизводится ?
------- Comment #74 From 2005-06-15 14:02:38 -------
Наверняка. Нужно заняться.
------- Comment #75 From 2005-07-13 10:47:46 -------
Женя, можешь проверить/починить?
------- Comment #76 From 2005-07-13 21:44:56 -------
Проверить не могу - модема под рукой нет.
Может быть на выходные возьму и поиграюсь - у меня раньше бага всегда
воспроизводилась... Даже когда все говорили fixed:)
------- Comment #77 From 2005-07-21 21:08:53 -------
А как в etcnet сейчас решается проблема? Раньше был RESOLV_MODS=yes или типа  
того.  
Я хоть kppp пропатчу, чтоб экспортировал переменную, когда надо. 
------- Comment #78 From 2005-07-29 17:44:45 -------
Код, модифицирующий resolv.conf, я переношу в ppp-common.
------- Comment #79 From 2005-08-01 18:37:43 -------
(In reply to comment #78) 
> Код, модифицирующий resolv.conf, я переношу в ppp-common. 
А почему не в etcnet? 
------- Comment #80 From 2005-08-04 00:46:33 -------
Разбиваем бутылку шампанского о борт ppp-common-0.3 и начинаем бахать хлопушки
над праздничным столом!
------- Comment #81 From 2007-12-22 01:23:02 -------
(In reply to comment #15)
> Я кажется нашел, с чем это может быть связано. 
> D kppp есть функция addperrdns, которая из /etc/ppp/resolv.conf 
> копирует все строки, добивая в конце каждой "#kppp temp entry" 
Вот.  А теперь смотрим в ip-up из ppp-common-0.4-alt1 и сравниваем логику -- мне
она кажется "трогать /etc/resolv.conf, если в нём _есть_ волшебная temp entry":

---
if ! is_no "$RESOLV_MODS"; then
        # for dynamic DNS support with gnome-ppp and kppp and draknet (adsl)
        if grep -iqs '#.*ppp temp entry' /etc/resolv.conf; then
                PPP_TEMP_ENTRY=`grep '#.*ppp temp entry' /etc/resolv.conf | \
                tail -1 | sed 's/.*ppp temp entry/# ppp temp entry/' `
        else
                unset PPP_TEMP_ENTRY
        fi
        [ -n "$PPP_TEMP_ENTRY" ] && modify_resolver
fi
---

Мне кажется, что здесь получилось нагромождение каких-то хаков и костылей со
времён Mdk 7.x и смысл этой кривулины вдруг поменялся на противоположный --
вместо того, чтоб _не трогать_ то, где она уже есть, теперь только так оно и
трогается!  В результате сейчас не обновляются по умолчанию DNS при
использовании всего подряд, мне вот про chestnut-dialer и pptp/pppoe уже почти
заслуженно плешь проели.

Плюс я всё-таки не понял, какова ценность функциональности kppp по засовыванию
рук в /etc/resolv.conf -- может, это для кривых дистрибутивов без ip-up или со
сломанным? (как вот у нас сейчас) => поддерживаю asy@ в том, что нефиг звонилке
бегать из-под рута и заниматься не своим делом.

Итог: в понедельник надеюсь взять в руки все наличные у нас звонилки и способы
подъёма интерфейсов (кроме разве что net-scripts) и проверить, выкинув или
инвертировав проверку на "ppp temp entry" в _ip-up_ (возможно, добавлю зачистку
в ip-down).  Если кто доберётся раньше или хотя бы проверит и
подтвердит/опровергнет эти мои соображения -- спасибо.
------- Comment #82 From 2007-12-22 17:26:29 -------
Подтверждаю: без этой temp entry при ifup ppp0 в resolv.conf ничего не
попадает.
Оно и понятно.