Bug 33300 - bind перестаёт работать с интерфейсом после ifup/ifdown
Summary: bind перестаёт работать с интерфейсом после ifup/ifdown
Status: CLOSED FIXED
Alias: None
Product: Sisyphus
Classification: Development
Component: bind (show other bugs)
Version: unstable
Hardware: all Linux
: P3 normal
Assignee: placeholder@altlinux.org
QA Contact: qa-sisyphus
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2017-03-29 20:55 MSK by Anton Farygin
Modified: 2022-04-13 11:01 MSK (History)
13 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Anton Farygin 2017-03-29 20:55:59 MSK
Имеем:
bind-9.10.4-alt2
пачку vpn туннелей в разные стороны (openvpn).
форвардинг запросов dns через vpn туннели к другим named серверам.

Проблемы:
bind перестаёт отправлять forward запросы на другой сервер, если интерфейс VPN переинициализируется по каким-то причинам (аналог ifdown && ifup)

после перезапуска bind снова начинает работать нормально.
Явно это из-за сброса capability. 

Меня бы устроила ручка по отключению такого поведения, ну или какое-то исправление, которое позволило бы bind садиться на те интерфейсы, которые появились после его запуска.

Аналогичная проблема с dhcp, но там не vpn а vlan'ы - после ifdown/ifup на интерфейсе приходится перезапускать dhcp сервер.
Comment 1 Sergey Y. Afonin 2017-03-30 11:24:34 MSK
interface-interval не эта ли ручка ?
Comment 2 Sergey Y. Afonin 2017-03-30 11:29:30 MSK
Кстати, а почему бы не добавить IP на lo и повесить BIND на этот адрес ? И всё делать с этим src ip.
Comment 3 Anton Farygin 2017-03-30 11:39:25 MSK

interface-interval у нас не работает - bind не биндится на порт с диагностикой permission denied:

Mar 30 11:36:04 xxxxxxx named[20586]: listening on IPv4 interface vpn1, 172.22.0.1#53
Mar 30 11:36:04 xxxxxxx named[20586]: could not listen on UDP socket: permission denied
Mar 30 11:36:04 xxxxxxx named[20586]: creating IPv4 interface vpn1 failed; interface ignored

Можно, наверное, решить это через lo0 и маршруты, но ошибка не о том, какой костыль придумать для того, что бы обойти неработающий в нашей сборке функционал.
Comment 4 Anton Farygin 2017-04-07 15:30:22 MSK
PING.
Сегодня опять нарвался, правда на dhcpd, который теряет интерфейс после ifdown/ifup

Мне собирать ещё один bind+libbind в Sisyphus ?
Comment 5 Dmitry V. Levin 2017-04-07 15:42:08 MSK
(In reply to comment #4)
> PING.
> Сегодня опять нарвался, правда на dhcpd, который теряет интерфейс после
> ifdown/ifup
> 
> Мне собирать ещё один bind+libbind в Sisyphus ?

А как же ты жил все эти годы?  bind утратил эту возможность, когда стал непривилегированным, с версии 8.2.какой-то.
Comment 6 Mikhail Efremov 2017-04-07 16:41:06 MSK
(In reply to comment #5)
>  bind утратил эту возможность, когда стал
> непривилегированным, с версии 8.2.какой-то.

Мне помнится, что когда-то давно по этой причине для Кольчуги делался костыль, перезапускающий bind после ifdown/ifup.
Comment 7 Sergey Y. Afonin 2017-04-07 17:41:04 MSK
А мне, на самом деле, непонятен отказ от варианта повесить Bind на дополнительный рабочий адрес на lo. Никакие маршруты не требуются, надо только дописать в ifaces/lo/ipv4address ещё один IP, а-ля 10.1.1.1/32 и раздавать его на клиентские подключения в качестве DNS. default gw ведь на этот же сервер ведёт ? Ну и придёт запрос к этому IP на этот сервер сам собой.
Comment 8 Anton Farygin 2017-04-07 20:45:15 MSK
Чаще всего налетаешь на dhcpd.

если с bind ещё можно как-то выкрутиться, то с dhcp всё плохо.
Мне кажется, что dhcp сервер раньше так не работал. Но я могу ошибаться.
Comment 9 Anton Farygin 2017-04-07 20:45:54 MSK
(In reply to comment #7)
> А мне, на самом деле, непонятен отказ от варианта повесить Bind на
> дополнительный рабочий адрес на lo. Никакие маршруты не требуются, надо только
> дописать в ifaces/lo/ipv4address ещё один IP, а-ля 10.1.1.1/32 и раздавать его
> на клиентские подключения в качестве DNS. default gw ведь на этот же сервер
> ведёт ? Ну и придёт запрос к этому IP на этот сервер сам собой.

default gw не ведёт на этот сервер. Если б вёл.
Comment 10 Dmitry V. Levin 2017-04-13 07:50:37 MSK
(In reply to comment #8)
> Чаще всего налетаешь на dhcpd.
> 
> если с bind ещё можно как-то выкрутиться, то с dhcp всё плохо.
> Мне кажется, что dhcp сервер раньше так не работал. Но я могу ошибаться.

dhcp собирается и работает с библиотеками от bind-9.9.9-P5, упакованными в пакет libisc-export-dhcp-devel.
Comment 11 Anton Farygin 2017-04-13 07:54:35 MSK
Открутишь от него сброс привелегий ?
Comment 12 Dmitry V. Levin 2017-04-13 07:58:45 MSK
(In reply to comment #11)
> Открутишь от него сброс привелегий ?

Я думаю, что тот код в bind нерелевантен для dhcp.
По идее, поведение dhcp не должно было поменяться, потому что бибилиотеки не поменялись.
Comment 13 Anton Farygin 2017-04-13 08:03:55 MSK
релевантность кода можно легко проверить.
я допускаю, что помимо обновлений у меня могли поменяться usecase - появились отдельные vlan'ы, которые я стал перезапускать немного чаще обычного.

но в любом случае смысл остаётся тот же - DHCP и bind ведут себя одинаково - теряют интерфейс после его рестарта.
Comment 14 Sergey Bolshakov 2017-07-07 11:51:22 MSK
потерять же интерфейс можно не только его рестартом -- достаточно
моргнуть линку, и, если сеть под etcnet+ifplugd или systemd-networkd, то всё,
этот bind уже не bind, а так, массогабаритный муляж.
нужно это прекратить.
Comment 15 Anton Farygin 2017-07-07 11:53:03 MSK
Дима, можешь добавить опцию, позволяющую отключать подобное поведение у bind ?
Comment 16 Dmitry V. Levin 2017-07-07 14:00:02 MSK
(In reply to comment #14)
> потерять же интерфейс можно не только его рестартом -- достаточно
> моргнуть линку, и, если сеть под etcnet+ifplugd или systemd-networkd, то всё,

А зачем они это делают?

> этот bind уже не bind, а так, массогабаритный муляж.

И что, теперь весь сетевой софт должен из-за этого стать привилегированным?

> нужно это прекратить.

не лучше ли это прекратить там, где это появилось, т.е. на стороне софта, выводящего из строя сетевые интерфейсы?
Comment 17 Anton Farygin 2018-07-20 12:03:28 MSK
ifdown/ifup интерфейс и named/dhcp перестаёт работать неожиданно для администратора.

Сегодня опять словили.
Comment 18 Michael Shigorin 2018-07-20 12:10:55 MSK
(В ответ на комментарий №14)
> если сеть под etcnet+ifplugd или systemd-networkd
Э-ээ, а зачем так делать на сервере?  Там же работать должно.
ifplugd для ноутов пакетил, даже не для десктопов вообще-то.

PS: как ещё вариант -- воткнуть рестартилку в подъёмные скрипты,
где они там (в ppp это ip-up.d из того, куда недавно заглядывал).
Comment 19 Anton Farygin 2018-07-20 12:19:05 MSK
Миша, сейчас существует как минимум три штатных способа настраивать сеть.
Какую рестартилку ?
Надо просто добавить в bind опцию, отключающую такое поведение. Для случаев, когда нужно.
Comment 20 Sergey Bolshakov 2018-07-20 12:20:59 MSK
(In reply to comment #18)
> (В ответ на комментарий №14)
> > если сеть под etcnet+ifplugd или systemd-networkd
> Э-ээ, а зачем так делать на сервере?  Там же работать должно.
> ifplugd для ноутов пакетил, даже не для десктопов вообще-то.
> 
> PS: как ещё вариант -- воткнуть рестартилку в подъёмные скрипты,
> где они там (в ppp это ip-up.d из того, куда недавно заглядывал).

Миша, если ты не в курсе, то я поясню: в вашем bind (себе я вынужден пересобирать) некоторые штатные возможности специально оторваны.
Изобретать к такому bind парные костыли мне не хочется.
Comment 21 Dmitry V. Levin 2018-07-20 12:28:28 MSK
Раньше указание "interface-interval 0;" в options решало это проблему - bind переставал "терять" интерфейс.
Comment 22 Anton Farygin 2018-07-20 14:09:05 MSK
Конечно, эта опция не может помочь от рестарта интерфейса

Выглядит это так:

# ss -u -a -p '( sport = 53  )'
State  Recv-Q  Send-Q     Local Address:Port       Peer Address:Port                                                                                          
UNCONN 0       0            192.168.1.1:domain          0.0.0.0:*      users:(("named",pid=5423,fd=520),("named",pid=5423,fd=519),("named",pid=5423,fd=518))  
UNCONN 0       0              127.0.0.1:domain          0.0.0.0:*      users:(("named",pid=5423,fd=517),("named",pid=5423,fd=516),("named",pid=5423,fd=515))  
UNCONN 0       0                   [::]:domain             [::]:*      users:(("named",pid=5423,fd=514),("named",pid=5423,fd=513),("named",pid=5423,fd=512))  

# ifdown lan && ifup lan

# ss -u -a -p '( sport = 53  )'
State  Recv-Q  Send-Q     Local Address:Port       Peer Address:Port                                                                                          
UNCONN 0       0              127.0.0.1:domain          0.0.0.0:*      users:(("named",pid=5423,fd=517),("named",pid=5423,fd=516),("named",pid=5423,fd=515))  
UNCONN 0       0                   [::]:domain             [::]:*      users:(("named",pid=5423,fd=514),("named",pid=5423,fd=513),("named",pid=5423,fd=512))  

# /etc/init.d/bind restart
Stopping named service:                                                                                                                               [ DONE ]
Checking named configuration file syntax:                                                                                                             [ DONE ]
Starting named service:                                                                                                                               [ DONE ]

# ss -u -a -p '( sport = 53  )'
State  Recv-Q  Send-Q     Local Address:Port       Peer Address:Port                                                                                          
UNCONN 0       0            192.168.1.1:domain          0.0.0.0:*      users:(("named",pid=5711,fd=520),("named",pid=5711,fd=519),("named",pid=5711,fd=518))  
UNCONN 0       0              127.0.0.1:domain          0.0.0.0:*      users:(("named",pid=5711,fd=517),("named",pid=5711,fd=516),("named",pid=5711,fd=515))  
UNCONN 0       0                   [::]:domain             [::]:*      users:(("named",pid=5711,fd=514),("named",pid=5711,fd=513),("named",pid=5711,fd=512))
Comment 23 Anton Farygin 2018-11-13 19:02:28 MSK
Я снова поймал эту ошибку неприятным образом (перестаёт работать DNS сам по себе после отваливанивания vpn интерфейса, на котором висит bind).
Ты планируешь её как-то исправить?
Comment 24 Anton Farygin 2019-10-10 09:51:06 MSK
И я опять словил эту же проблему но уже на p9.

Предлагаю ещё раз посмотреть на код, который реализует такое поведение.
Comment 25 Sergey Y. Afonin 2019-10-10 10:51:19 MSK
(In reply to comment #16)

> > нужно это прекратить.
> 
> не лучше ли это прекратить там, где это появилось, т.е. на стороне софта,
> выводящего из строя сетевые интерфейсы?

Тут есть такой момент, что с упавшего интерфейса могут убираться разные штуки, например статические маршруты через него. И это ожидаемое поведение для тех, кто привых к железным маршрутизаторам. То есть, при пропадании линка интерфейс должен как-то среагировать, и это нормально. Но должно ли так себя прикладное ПО вести - вопрос открытый...
Comment 26 Anton Farygin 2019-10-10 11:40:56 MSK
Ну смотри, если пофилосовствовать, то например - у нас есть какая-то прикладная программа, которая использует к примеру СУБД. Она присоединилась к этой СУБД и эксплуатирует данное соединение всегда для своей работы. Перезапуск СУБД ведёт к разрыву этого соединения. Прикладная программа должна корректно отрабатывать такую ситуацию и либо падать (в связи с тем, что функций своих она выполнять не может) либо просто делать reconnect.

СУБД в данном контексте - это сетевой интерфейс, а прикладная программа - bind.

Мы запустили named, он сел на интерфейс, на котором он нам нужен. Далее мы этот интерфейс перезапустили. named остался работать, хотя своих функций так как ожидает от него администратор - он уже не выполняет.

Тут ещё накладывается то, что такая фича есть только у нас и больше ни у кого.
Comment 27 Stanislav Levin 2019-10-10 20:04:38 MSK
Проблема из-за сброса CAP_NET_BIND_SERVICE.

Альтовый сброс привилегий отличается от варианта апстрима.
Если в апстриме сброс до рабочего состояния(ruid, euid,suid: named; caps: net_bind_service, sys_resource +) происходит еще до загрузки конфигурации BIND'а.

То у нас это проходит в два этапа:
1) до загрузки конфигурации происходит сброс (ruid, euid, suid: named, named, 0; caps: net_bind_service, sys_resource +)
2) во время загрузки конфигурации (ruid, euid, suid: named, named, named; caps: )

Еще два немаловажных отличия заключаются в том, что апстрим не дропает флаг SECBIT_KEEP_CAPS и capability bounding set.

Пункт два происходит чуть-чуть(несколько долей секунды) позже запуска потока плагина bind-dyndb-ldap. Отсюда возникает рэйс, так как RT сигнал, сгенерированный setresuid из основного потока BIND, рвет соединение плагина с доменным сокетом LDAP. Но это решаемо в самом плагине.

А вот дроп (по моему мнению) CAP_NET_BIND_SERVICE можно отключить. Если Дмитрий не возражает, то я мог бы подготовить патч на патч. Хотелось бы узнать мнение, чтобы не тратить время впустую.
Comment 28 Dmitry V. Levin 2019-10-10 21:47:33 MSK
(In reply to comment #27)
> А вот дроп (по моему мнению) CAP_NET_BIND_SERVICE можно отключить. Если Дмитрий
> не возражает, то я мог бы подготовить патч на патч.

Тут всё обсуждение ровно о том, что мне нужно, чтобы никаких CAP'ов у работающего bind'а не было, Антон хочет, чтобы у него bind работал с CAP_NET_BIND_SERVICE, и удовлетворить эти противоположные желания одним и тем же bind'ом пока не получается.
Comment 29 Anton Farygin 2019-10-10 22:32:28 MSK
Мне кажется, что в каком-то из обсуждений мы сошлись на том, что должна быть опция -#, включающая нужное тебе поведение. 

Мы можем Стаса попросить это реализовать.
Comment 30 Stanislav Levin 2020-06-08 12:46:58 MSK
Ручка для BIND добавлена:
http://git.altlinux.org/tasks/archive/done/_246/252433/logs/events.5.1.log
Comment 31 Sergey Y. Afonin 2022-04-13 09:23:40 MSK
(In reply to Stanislav Levin from comment #30)

> Ручка для BIND добавлена:
> http://git.altlinux.org/tasks/archive/done/_246/252433/logs/events.5.1.log

Наверное надо было в changelog про этот баг добавить, а то за версией в задание лезть надо.

* Fri May 29 2020 Stanislav Levin <slev@altlinux> 9.11.19-alt3
- Placed Linux capabilities dropping under control(1).
Comment 32 Sergey Y. Afonin 2022-04-13 11:01:38 MSK
(In reply to Sergey Y. Afonin from comment #31)

> * Fri May 29 2020 Stanislav Levin <slev@altlinux> 9.11.19-alt3
> - Placed Linux capabilities dropping under control(1).

Описано и добавляется в /etc/sysconfig/bind