ALT Linux Bugzilla – #13789

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" (возможно, в понедельник).
> 
> > > оставим на совести апстрима)
> > Это вплоть до Троллей можно раскрутить. Ничего страшного, в общем-то.
> Где-то так и подумал, просто сейчас уже реже вижу (после каких-то иксов был
> праздник "плюются все" ;).

Бум считать, что исправил

Ну давай посчитаем.