kppp из kdenetwork-3.5.8-alt2 криво заносит полученные MS-DNS в resolv.conf: --- /etc/resolv.conf, /var/resolv/etc/resolv.conf search uafoss nameserver 213.169.64.100 nameserver 213.169.64.101 nameserver 192.168.1.1 nameserver 213.169.64.100 #kppp temp entry nameserver 213.169.64.101 #kppp temp entry --- /etc/ppp/resolv.conf nameserver 213.169.64.100 nameserver 213.169.64.101 Утверждение "kppp не лазит, если не включена (это по-умолчанию) соответствующая опция в его настройках" (https://bugzilla.altlinux.org/show_bug.cgi?id=4249#c28) сейчас подтвердить не могу: по умолчанию стоит автомат, и ещё как лазит. Есть предложение починить kppp методом переписывания текущих ip-up, ip-down из нашего ppp-common, раз уж так хочется делать чужую работу. Ужас в addpeerdns() меня лично убедил только в том, что этой программе suid вовсе ни к чему. Особенно с учётом того, что без него она у меня сейчас таки звонит (при наличии у пользователя прав на устройство). Тогда может быть разумно выставлять переменную окружения RESOLV_MODS=no ("не модифицировать resolv.conf") перед вызовом pppd. Или отключить/заблокировать в kppp этот UI по причине неработоспособности -- рабочая реализация засовывала бы полученные NS в начало списка, а не с O_APPEND.
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" (возможно, в понедельник). > > > > оставим на совести апстрима) > > Это вплоть до Троллей можно раскрутить. Ничего страшного, в общем-то. > Где-то так и подумал, просто сейчас уже реже вижу (после каких-то иксов был > праздник "плюются все" ;).
Бум считать, что исправил
Ну давай посчитаем.
