И к чему это приводит? Дайте сценарий для просмотра непорядка.

http://lists.altlinux.ru/pipermail/sisyphus/2004-May/041596.html 
 
Сценарий простой: 
присоединиться при помощи KPPP 
У него должна быть включены опции для автоматического определения DNS 
и для закрытия доступа к существующим DNS на время соединения. 
После завершения KPPP в /etc/resolv.conf должны остаться лишние строки. 
 

Так ведь есть же в /etc/ppp/ip-down строки 
subst "/nameserver $DNS1 $PPP_TEMP_ENTRY/d" /etc/resolv.conf 
subst "/nameserver $DNS2 $PPP_TEMP_ENTRY/d" /etc/resolv.conf 
 
У меня всё нормально удаляется. 

Не могу воспроизвести. В sisyphus@ отправлен запрос на доп. информацию.

> Так ведь есть же в /etc/ppp/ip-down строки 
у меня нет :-( 
net-scripts-0.4.7-alt1 

Господа, дайте мне пожалуйста в почту ls -lR /etc/sysconfig/network-scripts /etc/ppp

ip-down у меня без таких строк. net-scripts-0.4.8-alt1

(In reply to comment #7) 
> ip-down у меня без таких строк. net-scripts-0.4.8-alt1 
 
У меня еще пока не 0.4.8. Сейчас проапдейчусь... 
 

Вот чёрт. Скрипт /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.

 (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 проапдейтил, проблема на месте.   
 

По полученным листингам я теперь буду думать.

Может просто я в kppp сменю  
"#kppp temp entry" 
на какой-нибудь 
"# temp entry of kppp" ? 

А смысл? Так их одно регулярное выражение подхватывает, а так два нужно будет.
Дайте поэкспериментировать денёк.

(In reply to comment #12) 
 
> Может просто я в kppp сменю   
> "#kppp temp entry"  
> на какой-нибудь  
> "# temp entry of kppp" ?  
 
Все-таки, зачем оно, вообще, нужно ? Почему не убрать совсем прописывание DNS ? 
Пусть этим pppd занимается. 
 

Я кажется нашел, с чем это может быть связано. 
D kppp есть функция addperrdns, которая из /etc/ppp/resolv.conf 
копирует все строки, добивая в конце каждой "#kppp temp entry" 
 

> Почему не убрать совсем прописывание DNS ?  
> Пусть этим pppd занимается. 
А у него есть для этого gui-настройка, 
к тому же работающая из-под пользователя? 
 

(In reply to comment #14)
[...]
> Все-таки, зачем оно, вообще, нужно ? Почему не убрать совсем прописывание DNS ? 
> Пусть этим pppd занимается. 
У меня он этим не занимается, если запущен из-под kppp. Пожалуйста ничего пока в
kppp не меняйте.

> У меня он этим не занимается, если запущен из-под kppp. 
Возможно это связано с /etc/ppp/resolv.conf 
Но у меня здесь его нет, прикрепите кто-нибудь, я не помню, что там конкретно. 
 
> Пожалуйста ничего пока в kppp не меняйте. 
Не буду 

> Возможно это связано с /etc/ppp/resolv.conf  
> Но у меня здесь его нет, прикрепите кто-нибудь, я не помню, что там 
конкретно.  
 
---/etc/ppp/resolv.conf 
nameserver 10.1.1.1 
nameserver 10.1.2.1 
--- 
 
только две строчки 

Господа, у которых /etc/ppp/resolv.conf в наличии, удалите rp-pppoe-client или
/etc/ppp/resolv.conf, пока не исправится
https://bugzilla.altlinux.org/show_bug.cgi?id=4276

Причина мистического появления "# 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 (а звонилок у нас хватает), то обрабатывать это
как отдельный случай.
Есть пожелания или соображения?

Мне кажется, что Вы несколько погорячились с предложением удалить
rp-pppoe-client. Как люди будут выходит в инет? 

Тогда давайте чиниться одновременно.

Кто-нибудь, скажите !! ЗАЧЕМ ?!?!  
 
Зачем лазить в resolve.conf кому-то, кроме pppd ?  
Это нужно только в одном случае - если DNS задаются 
в ручную и usepeerdns не используется при запуске 
pppd. 
 

Давайте внесём ясность: pppd сам туда не лазит, он только сохраняет фрагмент,
подлежащий вставке, и запускает скрипт.

(In reply to comment #25) 
 
Ну, я это и имел ввиду. Зачем дублировать то, что уже сдлано, а потом еще и 
бороться с результатом этого дублирования ? Единственный момент, это придется 
во всех используемых звонилках отрывать, если до конца идти...  
 

Если все звонилки делятся на те, которые могут сами вставить содержимое
/etc/ppp/resolv.conf в /etc/resolv.conf и на те, которые вообще не трогают
/etc/resolv.conf, тогда я предлагаю следующее: ввести флаг вида KEEP_RESOLVCONF
где-нибудь в /etc/sysconfig/network, который будет определять, что ip-up и
ip-down не будут трогать /etc/resolv.conf.
Так все должны помириться.

(In reply to comment #24) 
> Кто-нибудь, скажите !! ЗАЧЕМ ?!?!   
>   
> Зачем лазить в resolve.conf кому-то, кроме pppd ?   
> Это нужно только в одном случае - если DNS задаются  
> в ручную 
прямо из kppp 
 
> и usepeerdns не используется при запуске  
> pppd.  
kppp не лазит, если не включена(это по-умолчанию) соответствующая опция в его 
настройках 
 

(In reply to comment #21) 
> удалять всё вида "#.*ppp temp entry" в ifdown-post 
А чем это может быть плохо? 
 

> А чем это может быть плохо? 
Сейчас не могу представить, чем. Но вдруг?

 (In reply to comment #26) 
> Ну, я это и имел ввиду. Зачем дублировать то, что уже сдлано 
Это понятие растяжимое 
KPPP не дублирует GUI, которого нет в ppp/net-scripts 
 

(In reply to comment #30) 
> > А чем это может быть плохо?  
> Сейчас не могу представить, чем. Но вдруг? 
Ща в devel@ спрошу  
 
 

(In reply to comment #28) 
 
> > и usepeerdns не используется при запуске   
> > pppd.   
 
> kppp не лазит, если не включена(это по-умолчанию) соответствующая опция в его  
> настройках  
 
Что за опция ? Не видел. Или речь про опцию автоопределения DNS ? Ну, так я 
понимаю, что она не только бесполезную правку resolve.conf инициирует, но и 
весьма полезный параметр usepeerdns в строку запуска pppd добавляет. Так ведь ? 
 

Если не использовать usepeerdns, то NS'ы в систему никак не попадут. Значит,
нужно использовать usepeerdns. Соответственно тогда NSы не только попадают в
/etc/ppp/resolv.conf, но и втягиваются в /etc/resolv.conf силами ip-up.
Соответственно звонилка тогда лазить в /etc/resolv.conf не должна. Если кто-то
может отучить от этого kppp и все остальные звонилки, пожалуйста. (Кстати, как
много их?).
Если же нет, то я ввожу флаг и делаю как планировал. Поведение по умолчанию от
старого отличаться не будет.

Противопоказание найдено: 
Mikhail Yakshin <greycat@altlinux>: 
> Э... Стоп... А если ppp-интерфейсов несколько?.. То что, при опускании  
> одного из них все их entries будут убиваться?.. 
 

(In reply to comment #28) 
  
> kppp не лазит, если не включена(это по-умолчанию) соответствующая опция в 
его  
> настройках  
Обманул, лазит он, если вкючено (это по-умолчанию) автоматическое определение 
dns, но не создает строк с "#entry disabled by kppp", если выключена(это 
по-умолчанию) опция закрытия доступа к существующим DNS на время соединения. 
 
Про такие строки ip-up не знает. 
 

(In reply to comment #35)
> > Э... Стоп... А если ppp-интерфейсов несколько?.. То что, при опускании  
> > одного из них все их entries будут убиваться?.. 
Если имеется в виду машина с одним ppp-интерфейсом с выдачей DNS-серверов и
одним или более более простых, то да. Предлагаете перескочить на #
ppp{0|1|2|3...} temp entry и более сложную логику?

(In reply to comment #36)
[...]
> Обманул, лазит он, если вкючено (это по-умолчанию) автоматическое определение 
> dns, но не создает строк с "#entry disabled by kppp", если выключена(это 
> по-умолчанию) опция закрытия доступа к существующим DNS на время соединения. 
Не создаёт. Автоопредление + закрытие были включены.

> Про такие строки ip-up не знает. 
Не знает, поэтому пропускает.

(In reply to comment #37) 
 
> Если имеется в виду машина с одним ppp-интерфейсом с выдачей DNS-серверов и 
> одним или более более простых, то да. Предлагаете перескочить на # 
> ppp{0|1|2|3...} temp entry и более сложную логику? 
 
Зачем в системе толпа работающих DNS ? Мне кажется, даже если PPP интерфейсов 
несколько, использовать usepeerdns более, чем на одном пире идея достаточно 
непонятная. Уж лучше тогда их руками все прописать... В общем, не думаю, что 
стоит усложнять и стоит просто документировать необходимость использования 
usepeerdns не более, чем у одного pppd. И, вообще, в этом случае надо 
кэширующий DNS поднимать локально и уже его конфигурить. 
 

Да. На текущий момент ограничимся предположением, что usepeerdns автоматически
подразумевает не более одного ppp-интерфейса.
И к понедельнику я постараюсь предоставить наконец-то решение.

1. kppp не закрывает существующие nameserver
2. Возможно, это и есть решение исходной проблемы: добавьте в
/etc/sysconfig/network строку RESOLV_MODS=no, скрипты после этого не должны
менять resolv.conf.

Если никто не напишет обратного, то я считаю, что проблема решена.

(In reply to comment #42) 
> Если никто не напишет обратного, то я считаю, что проблема решена. 
 
Т.е. по-умолчанию она остается? 

Например, у меня по умолчанию сейчас не проявляется, хотя когда-то проявлялось.
Предлагаю отметить в документации, что есть такая переменная и если
конфигурацией DNS занимается только kppp, то её нужно установить.

(In reply to comment #44) 
> Например, у меня по умолчанию сейчас не проявляется, 
Это хорошо. 
А вообще я бы и в kppp какой-нибудь workaround сделал, 
чтоб пользователям kppp не нужно было ничего настраивать в связи с этим. 
Только уже запутался, что нужно. 
Убирать все "#.*ppp temp entry" а не только "#kppp temp entry" ? 
 

Давайте kppp не трогать, иначе будет полная неразбериха.

(In reply to comment #46) 
> Давайте kppp не трогать, иначе будет полная неразбериха. 
Ok 

Что-то у меня RESOLV_MODS=no эффекта не дает... 
 
 

> Что-то у меня RESOLV_MODS=no эффекта не дает... 
То есть добавляется каждый раз по паре "# ppp temp entry"? Не верю.

Я всё понял. Ждите новых net-scripts.
<Pilot> а решение будет таким: RESOLV_MODS должен обрабатываться не только в
ifup-post
<Pilot> и вдобавок нужно оставить одно место, в котором правится resolv.conf, а
то так два раза получается

Пошло в net-scripts-0.4.9. Ставлю дубликат, но на самом деле RESOLVED FIXED,
попрошу взять в Master 2.4.

*** This bug has been marked as a duplicate of 2589 ***

Да, перестали дубли появляться.  

клево :-) 

*** Bug 4276 has been marked as a duplicate of this bug. ***

А кто сейчас убирает из /etc/resolv.conf строки nameserver, добавленные
/etc/ppp/ip-up? Они у меня почему-то остаются.

(In reply to comment #55)
> А кто сейчас убирает из /etc/resolv.conf строки nameserver, добавленные
> /etc/ppp/ip-up? Они у меня почему-то остаются.
Опишите пожалуйста конфигурацию.

Установлен 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
После отключения эти строки остаются и впоследствии только плодятся.
Может у меня чего не так? Ткните, какой скрипт их должен удалять?

Я понял причину.

Кстати, ifcfg-ppp0 и chat-ppp0 в наличии?

Господа, ставлю block на master, ибо после дня использования kppp я свой
resolv.conf потерял ;-(

Система - самый последний Sisyphus. Т.е. - в master эта ошибка наблюдается.

Подтвердить/опровергнуть не могу, я после первого успешного исправления 
net-scripts дома не апдейтил. Сегодня проапдейчуть по такому случаю. Для 
статистики... 
 

(In reply to comment #60)
> Господа, ставлю block на master, ибо после дня использования kppp я свой
> resolv.conf потерял ;-(
Что там было и что осталось? Наличие ifcfg-ppp0?

> Система - самый последний Sisyphus. Т.е. - в master эта ошибка наблюдается.
0.4.9.1, другими словами.

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, которые не предназначены 
для доступа с любой точки сети. 
 

(In reply to comment #59)
> Кстати, ifcfg-ppp0 и chat-ppp0 в наличии?

Нет, отсутствуют.

(In reply to comment #60)
Проблема решается, если обозначить 'RESOLV_MODS=no' в /etc/sysconfig/network?

Интересно, новый баг завести, или здесь писать... 
В общем, теперь из 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 
 

(In reply to comment #66) 
> В общем, теперь из resolv.conf просто каша получается.  
Видимо из-за того, что /etc/ppp/resolv.conf - ссылка на /etc/resolv.conf 
 
 

(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 
 
 
 
 
 
 
 

(In reply to comment #68) 
> А почему бы ее не удалять ? 
Меня больше волнует, почему это ссылка, а не файл. 

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

(In reply to comment #70) 
> Был поставлен Master 2.4 DVD, затем был dist-upgrade в Сизиф. Больше ничего 
не  
> делалось, на сколько я помню.   
У меня без Сизифа на М2.4 ссылка 

Чтобы понять, откуда взялся симлинк /etc/ppp/resolv.conf, смотрите комментарий
#20 этой эпической саги и ссылку, в нём приведённую.

все еще воспроизводится ?

Наверняка. Нужно заняться.

Женя, можешь проверить/починить?

Проверить не могу - модема под рукой нет.
Может быть на выходные возьму и поиграюсь - у меня раньше бага всегда
воспроизводилась... Даже когда все говорили fixed:)

А как в etcnet сейчас решается проблема? Раньше был RESOLV_MODS=yes или типа  
того.  
Я хоть kppp пропатчу, чтоб экспортировал переменную, когда надо. 

Код, модифицирующий resolv.conf, я переношу в ppp-common.

(In reply to comment #78) 
> Код, модифицирующий resolv.conf, я переношу в ppp-common. 
А почему не в etcnet? 

Разбиваем бутылку шампанского о борт ppp-common-0.3 и начинаем бахать хлопушки
над праздничным столом!

(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).  Если кто доберётся раньше или хотя бы проверит и
подтвердит/опровергнет эти мои соображения -- спасибо.

Подтверждаю: без этой temp entry при ifup ppp0 в resolv.conf ничего не попадает.
Оно и понятно.