4249 2004-05-28 14:29:31 +0400 stuck "# ppp temp entry" in /etc/resolv.conf 2021-11-04 14:24:33 +0300 1 1 4 Development Sisyphus ppp-common unstable all Linux CLOSED FIXED P2 critical --- 3459 7079 13773 1 zerg placeholder ahmedsayeed1982 asy dav eostapets glebfm ldv mike pilot placeholder sass sbolshakov vt qa-sisyphus oldest_to_newest 14378 0 zerg 2004-05-28 14:29:31 +0400 После 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 14381 1 pilot 2004-05-28 15:31:49 +0400 И к чему это приводит? Дайте сценарий для просмотра непорядка. 14388 2 zerg 2004-05-28 17:31:06 +0400 http://lists.altlinux.ru/pipermail/sisyphus/2004-May/041596.html Сценарий простой: присоединиться при помощи KPPP У него должна быть включены опции для автоматического определения DNS и для закрытия доступа к существующим DNS на время соединения. После завершения KPPP в /etc/resolv.conf должны остаться лишние строки. 14394 3 dav 2004-05-29 01:51:53 +0400 Так ведь есть же в /etc/ppp/ip-down строки subst "/nameserver $DNS1 $PPP_TEMP_ENTRY/d" /etc/resolv.conf subst "/nameserver $DNS2 $PPP_TEMP_ENTRY/d" /etc/resolv.conf У меня всё нормально удаляется. 14402 4 pilot 2004-05-29 18:57:04 +0400 Не могу воспроизвести. В sisyphus@ отправлен запрос на доп. информацию. 14420 5 zerg 2004-05-31 09:36:34 +0400 > Так ведь есть же в /etc/ppp/ip-down строки у меня нет :-( net-scripts-0.4.7-alt1 14433 6 pilot 2004-05-31 15:03:03 +0400 Господа, дайте мне пожалуйста в почту ls -lR /etc/sysconfig/network-scripts /etc/ppp 14438 7 pilot 2004-05-31 16:57:32 +0400 ip-down у меня без таких строк. net-scripts-0.4.8-alt1 14445 8 asy 2004-05-31 19:42:25 +0400 (In reply to comment #7) > ip-down у меня без таких строк. net-scripts-0.4.8-alt1 У меня еще пока не 0.4.8. Сейчас проапдейчусь... 14448 9 dav 2004-05-31 20:21:42 +0400 Вот чёрт. Скрипт /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. 14449 10 asy 2004-05-31 20:36:58 +0400 (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 проапдейтил, проблема на месте. 14454 11 pilot 2004-06-01 00:12:55 +0400 По полученным листингам я теперь буду думать. 14463 12 zerg 2004-06-01 12:01:38 +0400 Может просто я в kppp сменю "#kppp temp entry" на какой-нибудь "# temp entry of kppp" ? 14464 13 pilot 2004-06-01 12:24:31 +0400 А смысл? Так их одно регулярное выражение подхватывает, а так два нужно будет. Дайте поэкспериментировать денёк. 14468 14 asy 2004-06-01 14:10:53 +0400 (In reply to comment #12) > Может просто я в kppp сменю > "#kppp temp entry" > на какой-нибудь > "# temp entry of kppp" ? Все-таки, зачем оно, вообще, нужно ? Почему не убрать совсем прописывание DNS ? Пусть этим pppd занимается. 14469 15 zerg 2004-06-01 14:44:31 +0400 Я кажется нашел, с чем это может быть связано. D kppp есть функция addperrdns, которая из /etc/ppp/resolv.conf копирует все строки, добивая в конце каждой "#kppp temp entry" 14470 16 zerg 2004-06-01 14:48:13 +0400 > Почему не убрать совсем прописывание DNS ? > Пусть этим pppd занимается. А у него есть для этого gui-настройка, к тому же работающая из-под пользователя? 14471 17 pilot 2004-06-01 15:05:25 +0400 (In reply to comment #14) [...] > Все-таки, зачем оно, вообще, нужно ? Почему не убрать совсем прописывание DNS ? > Пусть этим pppd занимается. У меня он этим не занимается, если запущен из-под kppp. Пожалуйста ничего пока в kppp не меняйте. 14472 18 zerg 2004-06-01 15:40:50 +0400 > У меня он этим не занимается, если запущен из-под kppp. Возможно это связано с /etc/ppp/resolv.conf Но у меня здесь его нет, прикрепите кто-нибудь, я не помню, что там конкретно. > Пожалуйста ничего пока в kppp не меняйте. Не буду 14473 19 asy 2004-06-01 15:48:15 +0400 > Возможно это связано с /etc/ppp/resolv.conf > Но у меня здесь его нет, прикрепите кто-нибудь, я не помню, что там конкретно. ---/etc/ppp/resolv.conf nameserver 10.1.1.1 nameserver 10.1.2.1 --- только две строчки 14489 20 pilot 2004-06-02 01:03:20 +0400 Господа, у которых /etc/ppp/resolv.conf в наличии, удалите rp-pppoe-client или /etc/ppp/resolv.conf, пока не исправится https://bugzilla.altlinux.org/show_bug.cgi?id=4276 14490 21 pilot 2004-06-02 01:42:57 +0400 Причина мистического появления "# 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 (а звонилок у нас хватает), то обрабатывать это как отдельный случай. Есть пожелания или соображения? 14516 22 sass 2004-06-02 13:29:47 +0400 Мне кажется, что Вы несколько погорячились с предложением удалить rp-pppoe-client. Как люди будут выходит в инет? 14521 23 pilot 2004-06-02 13:39:52 +0400 Тогда давайте чиниться одновременно. 14564 24 asy 2004-06-02 22:26:27 +0400 Кто-нибудь, скажите !! ЗАЧЕМ ?!?! Зачем лазить в resolve.conf кому-то, кроме pppd ? Это нужно только в одном случае - если DNS задаются в ручную и usepeerdns не используется при запуске pppd. 14565 25 pilot 2004-06-02 22:42:41 +0400 Давайте внесём ясность: pppd сам туда не лазит, он только сохраняет фрагмент, подлежащий вставке, и запускает скрипт. 14567 26 asy 2004-06-03 01:01:22 +0400 (In reply to comment #25) Ну, я это и имел ввиду. Зачем дублировать то, что уже сдлано, а потом еще и бороться с результатом этого дублирования ? Единственный момент, это придется во всех используемых звонилках отрывать, если до конца идти... 14572 27 pilot 2004-06-03 07:49:45 +0400 Если все звонилки делятся на те, которые могут сами вставить содержимое /etc/ppp/resolv.conf в /etc/resolv.conf и на те, которые вообще не трогают /etc/resolv.conf, тогда я предлагаю следующее: ввести флаг вида KEEP_RESOLVCONF где-нибудь в /etc/sysconfig/network, который будет определять, что ip-up и ip-down не будут трогать /etc/resolv.conf. Так все должны помириться. 14574 28 zerg 2004-06-03 11:26:58 +0400 (In reply to comment #24) > Кто-нибудь, скажите !! ЗАЧЕМ ?!?! > > Зачем лазить в resolve.conf кому-то, кроме pppd ? > Это нужно только в одном случае - если DNS задаются > в ручную прямо из kppp > и usepeerdns не используется при запуске > pppd. kppp не лазит, если не включена(это по-умолчанию) соответствующая опция в его настройках 14575 29 zerg 2004-06-03 11:30:40 +0400 (In reply to comment #21) > удалять всё вида "#.*ppp temp entry" в ifdown-post А чем это может быть плохо? 14580 30 pilot 2004-06-03 11:33:44 +0400 > А чем это может быть плохо? Сейчас не могу представить, чем. Но вдруг? 14581 31 zerg 2004-06-03 11:34:38 +0400 (In reply to comment #26) > Ну, я это и имел ввиду. Зачем дублировать то, что уже сдлано Это понятие растяжимое KPPP не дублирует GUI, которого нет в ppp/net-scripts 14582 32 zerg 2004-06-03 11:35:38 +0400 (In reply to comment #30) > > А чем это может быть плохо? > Сейчас не могу представить, чем. Но вдруг? Ща в devel@ спрошу 14602 33 asy 2004-06-03 16:05:49 +0400 (In reply to comment #28) > > и usepeerdns не используется при запуске > > pppd. > kppp не лазит, если не включена(это по-умолчанию) соответствующая опция в его > настройках Что за опция ? Не видел. Или речь про опцию автоопределения DNS ? Ну, так я понимаю, что она не только бесполезную правку resolve.conf инициирует, но и весьма полезный параметр usepeerdns в строку запуска pppd добавляет. Так ведь ? 14646 34 pilot 2004-06-03 17:35:29 +0400 Если не использовать usepeerdns, то NS'ы в систему никак не попадут. Значит, нужно использовать usepeerdns. Соответственно тогда NSы не только попадают в /etc/ppp/resolv.conf, но и втягиваются в /etc/resolv.conf силами ip-up. Соответственно звонилка тогда лазить в /etc/resolv.conf не должна. Если кто-то может отучить от этого kppp и все остальные звонилки, пожалуйста. (Кстати, как много их?). Если же нет, то я ввожу флаг и делаю как планировал. Поведение по умолчанию от старого отличаться не будет. 14692 35 zerg 2004-06-03 22:40:32 +0400 Противопоказание найдено: Mikhail Yakshin <greycat@altlinux>: > Э... Стоп... А если ppp-интерфейсов несколько?.. То что, при опускании > одного из них все их entries будут убиваться?.. 14693 36 zerg 2004-06-03 22:52:52 +0400 (In reply to comment #28) > kppp не лазит, если не включена(это по-умолчанию) соответствующая опция в его > настройках Обманул, лазит он, если вкючено (это по-умолчанию) автоматическое определение dns, но не создает строк с "#entry disabled by kppp", если выключена(это по-умолчанию) опция закрытия доступа к существующим DNS на время соединения. Про такие строки ip-up не знает. 14694 37 pilot 2004-06-03 23:15:09 +0400 (In reply to comment #35) > > Э... Стоп... А если ppp-интерфейсов несколько?.. То что, при опускании > > одного из них все их entries будут убиваться?.. Если имеется в виду машина с одним ppp-интерфейсом с выдачей DNS-серверов и одним или более более простых, то да. Предлагаете перескочить на # ppp{0|1|2|3...} temp entry и более сложную логику? 14695 38 pilot 2004-06-03 23:17:12 +0400 (In reply to comment #36) [...] > Обманул, лазит он, если вкючено (это по-умолчанию) автоматическое определение > dns, но не создает строк с "#entry disabled by kppp", если выключена(это > по-умолчанию) опция закрытия доступа к существующим DNS на время соединения. Не создаёт. Автоопредление + закрытие были включены. > Про такие строки ip-up не знает. Не знает, поэтому пропускает. 14699 39 asy 2004-06-04 10:42:52 +0400 (In reply to comment #37) > Если имеется в виду машина с одним ppp-интерфейсом с выдачей DNS-серверов и > одним или более более простых, то да. Предлагаете перескочить на # > ppp{0|1|2|3...} temp entry и более сложную логику? Зачем в системе толпа работающих DNS ? Мне кажется, даже если PPP интерфейсов несколько, использовать usepeerdns более, чем на одном пире идея достаточно непонятная. Уж лучше тогда их руками все прописать... В общем, не думаю, что стоит усложнять и стоит просто документировать необходимость использования usepeerdns не более, чем у одного pppd. И, вообще, в этом случае надо кэширующий DNS поднимать локально и уже его конфигурить. 14700 40 pilot 2004-06-04 11:08:00 +0400 Да. На текущий момент ограничимся предположением, что usepeerdns автоматически подразумевает не более одного ppp-интерфейса. И к понедельнику я постараюсь предоставить наконец-то решение. 15067 41 pilot 2004-06-13 16:08:50 +0400 1. kppp не закрывает существующие nameserver 2. Возможно, это и есть решение исходной проблемы: добавьте в /etc/sysconfig/network строку RESOLV_MODS=no, скрипты после этого не должны менять resolv.conf. 15098 42 pilot 2004-06-15 12:03:18 +0400 Если никто не напишет обратного, то я считаю, что проблема решена. 15101 43 zerg 2004-06-15 12:09:37 +0400 (In reply to comment #42) > Если никто не напишет обратного, то я считаю, что проблема решена. Т.е. по-умолчанию она остается? 15103 44 pilot 2004-06-15 12:25:11 +0400 Например, у меня по умолчанию сейчас не проявляется, хотя когда-то проявлялось. Предлагаю отметить в документации, что есть такая переменная и если конфигурацией DNS занимается только kppp, то её нужно установить. 15109 45 zerg 2004-06-15 13:02:42 +0400 (In reply to comment #44) > Например, у меня по умолчанию сейчас не проявляется, Это хорошо. А вообще я бы и в kppp какой-нибудь workaround сделал, чтоб пользователям kppp не нужно было ничего настраивать в связи с этим. Только уже запутался, что нужно. Убирать все "#.*ppp temp entry" а не только "#kppp temp entry" ? 15110 46 pilot 2004-06-15 13:23:30 +0400 Давайте kppp не трогать, иначе будет полная неразбериха. 15112 47 zerg 2004-06-15 14:03:26 +0400 (In reply to comment #46) > Давайте kppp не трогать, иначе будет полная неразбериха. Ok 15193 48 asy 2004-06-17 00:19:18 +0400 Что-то у меня RESOLV_MODS=no эффекта не дает... 15196 49 pilot 2004-06-17 10:23:28 +0400 > Что-то у меня RESOLV_MODS=no эффекта не дает... То есть добавляется каждый раз по паре "# ppp temp entry"? Не верю. 15244 50 pilot 2004-06-17 21:17:34 +0400 Я всё понял. Ждите новых net-scripts. <Pilot> а решение будет таким: RESOLV_MODS должен обрабатываться не только в ifup-post <Pilot> и вдобавок нужно оставить одно место, в котором правится resolv.conf, а то так два раза получается 15565 51 pilot 2004-06-24 21:55:17 +0400 Пошло в net-scripts-0.4.9. Ставлю дубликат, но на самом деле RESOLVED FIXED, попрошу взять в Master 2.4. *** This bug has been marked as a duplicate of 2589 *** 15669 52 asy 2004-06-27 12:39:19 +0400 Да, перестали дубли появляться. 16346 53 zerg 2004-07-02 20:10:39 +0400 клево :-) 16740 54 sass 2004-07-08 12:01:52 +0400 *** Bug 4276 has been marked as a duplicate of this bug. *** 17193 55 dav 2004-07-17 06:30:50 +0400 А кто сейчас убирает из /etc/resolv.conf строки nameserver, добавленные /etc/ppp/ip-up? Они у меня почему-то остаются. 17774 56 pilot 2004-08-04 16:01:42 +0400 (In reply to comment #55) > А кто сейчас убирает из /etc/resolv.conf строки nameserver, добавленные > /etc/ppp/ip-up? Они у меня почему-то остаются. Опишите пожалуйста конфигурацию. 17853 57 dav 2004-08-06 03:51:16 +0400 Установлен 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 После отключения эти строки остаются и впоследствии только плодятся. Может у меня чего не так? Ткните, какой скрипт их должен удалять? 18030 58 pilot 2004-08-11 14:59:40 +0400 Я понял причину. 18176 59 pilot 2004-08-17 20:08:01 +0400 Кстати, ifcfg-ppp0 и chat-ppp0 в наличии? 18228 60 rider 2004-08-20 12:34:26 +0400 Господа, ставлю block на master, ибо после дня использования kppp я свой resolv.conf потерял ;-( Система - самый последний Sisyphus. Т.е. - в master эта ошибка наблюдается. 18234 61 asy 2004-08-20 14:04:41 +0400 Подтвердить/опровергнуть не могу, я после первого успешного исправления net-scripts дома не апдейтил. Сегодня проапдейчуть по такому случаю. Для статистики... 18237 62 pilot 2004-08-20 15:33:05 +0400 (In reply to comment #60) > Господа, ставлю block на master, ибо после дня использования kppp я свой > resolv.conf потерял ;-( Что там было и что осталось? Наличие ifcfg-ppp0? > Система - самый последний Sisyphus. Т.е. - в master эта ошибка наблюдается. 0.4.9.1, другими словами. 18275 63 asy 2004-08-22 18:05:51 +0400 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, которые не предназначены для доступа с любой точки сети. 18290 64 dav 2004-08-23 14:45:16 +0400 (In reply to comment #59) > Кстати, ifcfg-ppp0 и chat-ppp0 в наличии? Нет, отсутствуют. 18412 65 pilot 2004-08-30 12:52:05 +0400 (In reply to comment #60) Проблема решается, если обозначить 'RESOLV_MODS=no' в /etc/sysconfig/network? 20394 66 asy 2004-12-13 14:24:06 +0300 Интересно, новый баг завести, или здесь писать... В общем, теперь из 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 20406 67 zerg 2004-12-14 11:35:00 +0300 (In reply to comment #66) > В общем, теперь из resolv.conf просто каша получается. Видимо из-за того, что /etc/ppp/resolv.conf - ссылка на /etc/resolv.conf 20414 68 asy 2004-12-14 13:25:36 +0300 (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 20418 69 zerg 2004-12-14 13:53:42 +0300 (In reply to comment #68) > А почему бы ее не удалять ? Меня больше волнует, почему это ссылка, а не файл. 20429 70 asy 2004-12-14 16:16:17 +0300 > Меня больше волнует, почему это ссылка, а не файл. Был поставлен Master 2.4 DVD, затем был dist-upgrade в Сизиф. Больше ничего не делалось, на сколько я помню. 20436 71 zerg 2004-12-14 16:39:29 +0300 (In reply to comment #70) > Был поставлен Master 2.4 DVD, затем был dist-upgrade в Сизиф. Больше ничего не > делалось, на сколько я помню. У меня без Сизифа на М2.4 ссылка 20438 72 pilot 2004-12-14 16:50:06 +0300 Чтобы понять, откуда взялся симлинк /etc/ppp/resolv.conf, смотрите комментарий #20 этой эпической саги и ссылку, в нём приведённую. 25665 73 rider 2005-06-14 12:34:27 +0400 все еще воспроизводится ? 25802 74 pilot 2005-06-15 14:02:38 +0400 Наверняка. Нужно заняться. 27212 75 mike 2005-07-13 10:47:46 +0400 Женя, можешь проверить/починить? 27253 76 eostapets 2005-07-13 21:44:56 +0400 Проверить не могу - модема под рукой нет. Может быть на выходные возьму и поиграюсь - у меня раньше бага всегда воспроизводилась... Даже когда все говорили fixed:) 27562 77 zerg 2005-07-21 21:08:53 +0400 А как в etcnet сейчас решается проблема? Раньше был RESOLV_MODS=yes или типа того. Я хоть kppp пропатчу, чтоб экспортировал переменную, когда надо. 27864 78 pilot 2005-07-29 17:44:45 +0400 Код, модифицирующий resolv.conf, я переношу в ppp-common. 27929 79 zerg 2005-08-01 18:37:43 +0400 (In reply to comment #78) > Код, модифицирующий resolv.conf, я переношу в ppp-common. А почему не в etcnet? 28043 80 pilot 2005-08-04 00:46:33 +0400 Разбиваем бутылку шампанского о борт ppp-common-0.3 и начинаем бахать хлопушки над праздничным столом! 59840 81 mike 2007-12-22 01:23:02 +0300 (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). Если кто доберётся раньше или хотя бы проверит и подтвердит/опровергнет эти мои соображения -- спасибо. 59860 82 hiddenman 2007-12-22 17:26:29 +0300 Подтверждаю: без этой temp entry при ifup ppp0 в resolv.conf ничего не попадает. Оно и понятно.