Summary: | broken resolv.conf handling | ||
---|---|---|---|
Product: | Sisyphus | Reporter: | Michael Shigorin <mike> |
Component: | kdenetwork-kppp | Assignee: | Nobody's working on this, feel free to take it <nobody> |
Status: | CLOSED FIXED | QA Contact: | qa-sisyphus |
Severity: | normal | ||
Priority: | P2 | CC: | ahmedsayeed1982, asy, boyarsh, hiddenman, jinn, vip0 |
Version: | unstable | ||
Hardware: | all | ||
OS: | Linux |
Description
Michael Shigorin
2007-12-24 17:04:54 MSK
PS: сломанный объезд для этого убран из ppp-common (ip-up), чтоб не ломать работу всего остального; можно воткнуть sleep, но тогда лучше будет действительно как-то определять, что работаем в итоге из-под kppp, чтоб не спать почём зря. (In reply to comment #0) > Тогда может быть разумно выставлять переменную окружения RESOLV_MODS=no ("не > модифицировать resolv.conf") перед вызовом pppd. В свое время Pilot больше этого ничего внятного сказать так и не смог. (In reply to comment #0) > Тогда может быть разумно выставлять переменную окружения RESOLV_MODS=no ("не > модифицировать resolv.conf") перед вызовом pppd. Это возможно только в /etc/net сделать (In reply to comment #0) > сейчас подтвердить не могу: по умолчанию стоит автомат, и ещё как лазит. А ты уверен, что это kppp не удалил за собой, а не pppd перезаписал сохраненное после того, как kppp за собой прибрался? У тебя есть на чём проверить? Если нет -- забрасывай патчики или сборки, тут стендовый модем и тестовый логин имени http://naverex.net наблюдаются :-) > А ты уверен, что это kppp не удалил за собой, а не pppd перезаписал > сохраненное после того, как kppp за собой прибрался? Копия /etc/resolv.conf в файле /etc/resolv.conf.save.$REALDEVICE создаётся скриптом /etc/ppp/ip-up только при отсутствии '#.*ppp temp entry' (и вот тут возможен ловимый ещё в #4249 рейс). Соответственно оригинал восстанавливается из этого файла только при его наличии. Оставил только это (редактированием /etc/resolv.conf после дозвона kppp): search uafoss nameserver 192.168.1.1 nameserver 213.169.64.100 #kppp temp entry nameserver 213.169.64.101 #kppp temp entry получил после отключения: # Generated by dhcpcd for interface eth0 search uafoss nameserver 192.168.1.111 nameserver 195.69.84.1 nameserver 212.40.36.150 Значит, kppp не успело модифицировать resolv.conf. Можешь сделать патчик с выставлением RESOLV_MODS="no"? (In reply to comment #5) > Можешь сделать патчик с выставлением RESOLV_MODS="no"? Я ж говорю, никто не сможет. pppd сбрасывает переменные. В принципе, сейчас для обычного случая ничего плохого и не происходит, но возможности kppp как GUI к resolv.conf в случае, когда там и так есть 1--3 DNS, частично или полностью блокируются (поскольку в рассмотрение идут только три первых nameserver). Если переписать этот кусочек connect.cpp (кажется) так, чтобы сперва добавлять свои NS, а потом перетаскивать всё остальное -- сложно/неинтересно, а переменные для нас не работают (pppd действительно очищает окружение) -- может, договоримся про файловый флажок где-нить в /var/run/ppp/users/ с правами 1777? :) (In reply to comment #7) > -- может, договоримся про файловый флажок А может, про текстовый в /etc/resolv.conf? ;-) Плохо тем, что он расистый очень. Т.е. он работает между коннектом (когда у тебя уже есть /etc/ppp/resolv.conf и ты с ним что-то начинаешь делать) и ip-up*. Если навтыкать sleep, то ими же надо будет обтыкивать все ip-up.d/*, которые могут хотеть резолвинг (по существу все). А файловый флажок хорош тем, что ты бы его мог выставить сильно заранее и тем избежать race. И чистить его при загрузке проще/надёжней (на случай, если питание пропало при поднятом линке -- наступали уже). (In reply to comment #9) > ты бы его мог выставить сильно заранее только "бы" мешает > и тем избежать race. в одном месте и сделать в другом > чистить его при загрузке проще/надёжней проще и надежнее делать это в _одном_месте_ нужно скрипты научить обрабатывать '#.*ppp temp entry' (In reply to comment #10) > > ты бы его мог выставить сильно заранее > только "бы" мешает Хорошо. Авторы kppp могли бы, если б не были такими криворукими (что дописывают своё в конец, а не в начало -- детская же ошибка). И нам с тобой бы не пришлось бы парить себе мозг :) > > и тем избежать race. > в одном месте и сделать в другом Я подумал перед тем, как предлагать такое разнесение. Можешь пояснить, где и как именно создаётся новый race? Существовавший уже разжёван здесь: https://bugzilla.altlinux.org/show_bug.cgi?id=4249#c21 (также #c34). Собственно, ты тогда согласился сделать через переменную в #c77, но это обломалось уже дальше. Поскольку файл для нас не работает (race между параллельно исполняющимися трогателями /etc/resolv.conf) и переменная -- тоже (очистка среды pppd), я как следующий простейший вариант и предлагаю файловый или каталожный флажок. > > чистить его при загрузке проще/надёжней > проще и надежнее делать это в _одном_месте_ Как показала практика, не надёжнее. > нужно скрипты научить обрабатывать '#.*ppp temp entry' Они продолжают уметь его обрабатывать, просто логика была перевёрнута -- эти строчки воспринимались как _условие_ для того, чтоб /etc/ppp/ip-up занимался /etc/resolv.conf. Сейчас так: grep -iqs '#.*ppp temp entry' /etc/resolv.conf || modify_resolver PS: мож нарисуй себе на бумажке происходящее, понятней станет. Думаешь, сколько лет я боялся сюда залазить? :) (In reply to comment #11) > своё в конец, а не в начало -- детская же ошибка Не сказал бы. Там похожее делается в других местах. Видимо, это не оказалось почему-то актуальным. Если только в этом проблема, то для kppp это решаемо. Патчить? > Я подумал перед тем, как предлагать такое разнесение. > Можешь пояснить, где и как именно создаётся новый race? Я могу абсолютно точно и без разжевывания пояснить, как новый race не появиться ;-) > или каталожный флажок. Этот флажок мне больше кажется перекладыванием проблемы с больной головы на здоровую. Вообще, возникла еще 1-а идея патченья kppp. Попробую. Если получиться, расскажу. kdenetwork-3.5.8-alt4 Сделал проверку /etc/sysconfig/network и недобавление , но чистку от своих записей оставил. Просьба проверить, а то у меня не на чем. RESOLV_MODS должен быть не пуст. В kdenetwork-3.5.8-alt5 исправлю. kdenetwork-3.5.8-alt5 Проверяйте. Как-минимум, хуже не станет. В бранч тоже отправлю (In reply to comment #12) > > своё в конец, а не в начало -- детская же ошибка > Не сказал бы. Там похожее делается в других местах. Значит, там делается много детских ошибок... > > Можешь пояснить, где и как именно создаётся новый race? > Я могу абсолютно точно и без разжевывания пояснить, как новый race > не появиться ;-) Иии? :-) > > или каталожный флажок. > Этот флажок мне больше кажется перекладыванием проблемы с больной головы > на здоровую. Вот только больная голова у нас -- это суидный kppp, который делает неподобающие вещи неподобающим образом. Возникла ещё более радикальная идея -- мож ты его научишь лезть не в /etc/resolv.conf, а опять же в левый файлик с известным путём, доступный по записи тем же, кому по control ppp, например, доступно выполнение pppd? Я его в ppp-common при наличии буду отрабатывать вместо переменных. (In reply to comment #16) > kdenetwork-3.5.8-alt5 > Проверяйте. Как-минимум, хуже не станет. > В бранч тоже отправлю Проверяю с обычным проводным модемом IDC (указал руками заведомо левый DNS, чтоб видно было, : Opener: received SetSecret Opener: received SetSecret Opener: received OpenLock Opener: received OpenDevice Opener: received ExecPPPDaemon In parent: pppd pid 31332 Couldn't find interface ppp0: No such device Kernel supports ppp alright. Opener: received RemoveSecret Opener: received RemoveSecret На этой стадии соединение установлено; маршрут по умолчанию via ppp0; /etc/resolv.conf -- такой, как был; в /etc/sysconfig/network -- RESOLV_MODS=yes. (мы там ещё много плюёмся X Error: BadWindow (invalid Window parameter), но это оставим на совести апстрима) > Возникла ещё более радикальная идея -- мож ты его научишь лезть не в
> /etc/resolv.conf, а опять же в левый файлик с известным путём
в смысле "и положишь туда NS'ы и домен"
(In reply to comment #17) > > Я могу абсолютно точно и без разжевывания пояснить, как новый race > > не появиться ;-) > Иии? :-) Даже молчанием могу ;-) > Вот только больная голова у нас -- это суидный kppp, > который делает неподобающие вещи неподобающим образом. Давай сделаем такой kppp, как другие? ;-) > записи тем же, кому по control ppp, например, доступно выполнение pppd? Ну не нравиться мне новое извращение "флажок" :-) > Проверяю [...] > На этой стадии соединение установлено; маршрут по умолчанию via ppp0; > /etc/resolv.conf -- такой, как был; в /etc/sysconfig/network -- RESOLV_MODS=yes. А pppd был с peerdns запущен kppp-ом? В kppp должно быть включено "Автоматическая настройка DNS" [...] > (мы там ещё много плюёмся X Error: BadWindow (invalid Window parameter), но это > оставим на совести апстрима) Это вплоть до Троллей можно раскрутить. Ничего страшного, в общем-то. (In reply to comment #18) > > Возникла ещё более радикальная идея -- мож ты его научишь лезть не в > > /etc/resolv.conf, а опять же в левый файлик с известным путём > в смысле "и положишь туда NS'ы и домен" Я научил его лезть в /etc/sysconfig/network и не ложить ничего в /etc/resolv.conf, если это и так делается. Оставил только чистку /etc/resolv.conf от "#kppp temp entry" Только поэтому прошу проверить, не остался ли race (In reply to comment #20) > Оставил только чистку /etc/resolv.conf от "#kppp temp entry" Для того, чтоб почистить, что уже загажено. Т.е., если race есть, то и это выключу. (In reply to comment #19) > > > Я могу абсолютно точно и без разжевывания пояснить, как новый race > > > не появиться ;-) > > Иии? :-) > Даже молчанием могу ;-) Ну когда ещё встретимся, чтоб его выслушать :-) > > Вот только больная голова у нас -- это суидный kppp, > > который делает неподобающие вещи неподобающим образом. > Давай сделаем такой kppp, как другие? ;-) А какой сейчас у других? > > записи тем же, кому по control ppp, например, доступно выполнение pppd? > Ну не нравиться мне новое извращение "флажок" :-) Мне тоже... но то, что там прочитал, не нравится ещё сильнее. > > На этой стадии соединение установлено; маршрут по умолчанию via ppp0; > > /etc/resolv.conf -- такой, как был; в /etc/sysconfig/network -- > RESOLV_MODS=yes. > А pppd был с peerdns запущен kppp-ом? Не факт. > В kppp должно быть включено "Автоматическая настройка DNS" Вообще-то я имел в виду, что если автонастройка включена -- то нам нет смысла задействовать обработку DNS1/DNS2 в kppp, поскольку с этим прекрасно справляется ip-up.d; а вот в случае, когда именно при поднятом дайлапе надо вручную поставить НС-ы и домен (возможно, для каждого аккаунта -- свои) -- да, пожалуй что лучше оставить это звонилке. Хотя случай ближе к гипотетическому -- кто знает, что туда _разного_ писать, обычно имеет broadband и/или VPN, а кто не знает -- для тех ISP без автомата давно вымерли. Короче говоря, тестировал единственный оставшийся разумным случай, но не поняв, что ты таки читаешь (а не пишешь) RESOLV_MODS. OK, проверю при его значении "no" (возможно, в понедельник). > > оставим на совести апстрима) > Это вплоть до Троллей можно раскрутить. Ничего страшного, в общем-то. Где-то так и подумал, просто сейчас уже реже вижу (после каких-то иксов был праздник "плюются все" ;). (In reply to comment #22) > Вообще-то я имел в виду, что если автонастройка включена -- то нам нет > смысла задействовать обработку DNS1/DNS2 в kppp, > поскольку с этим прекрасно справляется ip-up.d Да. Я сделал "обработку DNS1/DNS2" в зависимости от значения RESOLV_MODS Но я не выключал чистку resolv.conf от строк , оканчивающихся "#kppp temp entry" или раскомментирования строк, содержащих "#entry disabled by kppp" Это все в одной функции, поэтому для проверки подойдут любые варианты: Напихать в /etc/resolv.conf несколько строк, в конце которых есть "#kppp temp entry" или #entry disabled by kppp". ; а вот в случае, когда именно при поднятом дайлапе надо вручную > поставить НС-ы и домен (возможно, для каждого аккаунта -- свои) -- да, пожалуй > что лучше оставить это звонилке. Хотя случай ближе к гипотетическому -- кто > знает, что туда _разного_ писать, обычно имеет broadband и/или VPN, а кто не > знает -- для тех ISP без автомата давно вымерли. > > Короче говоря, тестировал единственный оставшийся разумным случай, но не поняв, > что ты таки читаешь (а не пишешь) RESOLV_MODS. > > OK, проверю при его значении "no" (возможно, в понедельник). > > > > оставим на совести апстрима) > > Это вплоть до Троллей можно раскрутить. Ничего страшного, в общем-то. > Где-то так и подумал, просто сейчас уже реже вижу (после каких-то иксов был > праздник "плюются все" ;). Бум считать, что исправил Ну давай посчитаем. |