interface-interval не эта ли ручка ?

Кстати, а почему бы не добавить IP на lo и повесить BIND на этот адрес ? И всё делать с этим src ip.

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 и маршруты, но ошибка не о том, какой костыль придумать для того, что бы обойти неработающий в нашей сборке функционал.

PING.
Сегодня опять нарвался, правда на dhcpd, который теряет интерфейс после ifdown/ifup

Мне собирать ещё один bind+libbind в Sisyphus ?

(In reply to comment #4)
> PING.
> Сегодня опять нарвался, правда на dhcpd, который теряет интерфейс после
> ifdown/ifup
> 
> Мне собирать ещё один bind+libbind в Sisyphus ?

А как же ты жил все эти годы?  bind утратил эту возможность, когда стал непривилегированным, с версии 8.2.какой-то.

(In reply to comment #5)
>  bind утратил эту возможность, когда стал
> непривилегированным, с версии 8.2.какой-то.

Мне помнится, что когда-то давно по этой причине для Кольчуги делался костыль, перезапускающий bind после ifdown/ifup.

А мне, на самом деле, непонятен отказ от варианта повесить Bind на дополнительный рабочий адрес на lo. Никакие маршруты не требуются, надо только дописать в ifaces/lo/ipv4address ещё один IP, а-ля 10.1.1.1/32 и раздавать его на клиентские подключения в качестве DNS. default gw ведь на этот же сервер ведёт ? Ну и придёт запрос к этому IP на этот сервер сам собой.

Чаще всего налетаешь на dhcpd.

если с bind ещё можно как-то выкрутиться, то с dhcp всё плохо.
Мне кажется, что dhcp сервер раньше так не работал. Но я могу ошибаться.

(In reply to comment #7)
> А мне, на самом деле, непонятен отказ от варианта повесить Bind на
> дополнительный рабочий адрес на lo. Никакие маршруты не требуются, надо только
> дописать в ifaces/lo/ipv4address ещё один IP, а-ля 10.1.1.1/32 и раздавать его
> на клиентские подключения в качестве DNS. default gw ведь на этот же сервер
> ведёт ? Ну и придёт запрос к этому IP на этот сервер сам собой.

default gw не ведёт на этот сервер. Если б вёл.

(In reply to comment #8)
> Чаще всего налетаешь на dhcpd.
> 
> если с bind ещё можно как-то выкрутиться, то с dhcp всё плохо.
> Мне кажется, что dhcp сервер раньше так не работал. Но я могу ошибаться.

dhcp собирается и работает с библиотеками от bind-9.9.9-P5, упакованными в пакет libisc-export-dhcp-devel.

Открутишь от него сброс привелегий ?

(In reply to comment #11)
> Открутишь от него сброс привелегий ?

Я думаю, что тот код в bind нерелевантен для dhcp.
По идее, поведение dhcp не должно было поменяться, потому что бибилиотеки не поменялись.

релевантность кода можно легко проверить.
я допускаю, что помимо обновлений у меня могли поменяться usecase - появились отдельные vlan'ы, которые я стал перезапускать немного чаще обычного.

но в любом случае смысл остаётся тот же - DHCP и bind ведут себя одинаково - теряют интерфейс после его рестарта.

потерять же интерфейс можно не только его рестартом -- достаточно
моргнуть линку, и, если сеть под etcnet+ifplugd или systemd-networkd, то всё,
этот bind уже не bind, а так, массогабаритный муляж.
нужно это прекратить.

Дима, можешь добавить опцию, позволяющую отключать подобное поведение у bind ?

(In reply to comment #14)
> потерять же интерфейс можно не только его рестартом -- достаточно
> моргнуть линку, и, если сеть под etcnet+ifplugd или systemd-networkd, то всё,

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

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

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

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

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

ifdown/ifup интерфейс и named/dhcp перестаёт работать неожиданно для администратора.

Сегодня опять словили.

(В ответ на комментарий №14)
> если сеть под etcnet+ifplugd или systemd-networkd
Э-ээ, а зачем так делать на сервере?  Там же работать должно.
ifplugd для ноутов пакетил, даже не для десктопов вообще-то.

PS: как ещё вариант -- воткнуть рестартилку в подъёмные скрипты,
где они там (в ppp это ip-up.d из того, куда недавно заглядывал).

Миша, сейчас существует как минимум три штатных способа настраивать сеть.
Какую рестартилку ?
Надо просто добавить в bind опцию, отключающую такое поведение. Для случаев, когда нужно.

(In reply to comment #18)
> (В ответ на комментарий №14)
> > если сеть под etcnet+ifplugd или systemd-networkd
> Э-ээ, а зачем так делать на сервере?  Там же работать должно.
> ifplugd для ноутов пакетил, даже не для десктопов вообще-то.
> 
> PS: как ещё вариант -- воткнуть рестартилку в подъёмные скрипты,
> где они там (в ppp это ip-up.d из того, куда недавно заглядывал).

Миша, если ты не в курсе, то я поясню: в вашем bind (себе я вынужден пересобирать) некоторые штатные возможности специально оторваны.
Изобретать к такому bind парные костыли мне не хочется.

Раньше указание "interface-interval 0;" в options решало это проблему - bind переставал "терять" интерфейс.

Конечно, эта опция не может помочь от рестарта интерфейса

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

# 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))

Я снова поймал эту ошибку неприятным образом (перестаёт работать DNS сам по себе после отваливанивания vpn интерфейса, на котором висит bind).
Ты планируешь её как-то исправить?

И я опять словил эту же проблему но уже на p9.

Предлагаю ещё раз посмотреть на код, который реализует такое поведение.

(In reply to comment #16)

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

Тут есть такой момент, что с упавшего интерфейса могут убираться разные штуки, например статические маршруты через него. И это ожидаемое поведение для тех, кто привых к железным маршрутизаторам. То есть, при пропадании линка интерфейс должен как-то среагировать, и это нормально. Но должно ли так себя прикладное ПО вести - вопрос открытый...

Ну смотри, если пофилосовствовать, то например - у нас есть какая-то прикладная программа, которая использует к примеру СУБД. Она присоединилась к этой СУБД и эксплуатирует данное соединение всегда для своей работы. Перезапуск СУБД ведёт к разрыву этого соединения. Прикладная программа должна корректно отрабатывать такую ситуацию и либо падать (в связи с тем, что функций своих она выполнять не может) либо просто делать reconnect.

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

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

Тут ещё накладывается то, что такая фича есть только у нас и больше ни у кого.

Проблема из-за сброса 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 можно отключить. Если Дмитрий не возражает, то я мог бы подготовить патч на патч. Хотелось бы узнать мнение, чтобы не тратить время впустую.

(In reply to comment #27)
> А вот дроп (по моему мнению) CAP_NET_BIND_SERVICE можно отключить. Если Дмитрий
> не возражает, то я мог бы подготовить патч на патч.

Тут всё обсуждение ровно о том, что мне нужно, чтобы никаких CAP'ов у работающего bind'а не было, Антон хочет, чтобы у него bind работал с CAP_NET_BIND_SERVICE, и удовлетворить эти противоположные желания одним и тем же bind'ом пока не получается.

Мне кажется, что в каком-то из обсуждений мы сошлись на том, что должна быть опция -#, включающая нужное тебе поведение. 

Мы можем Стаса попросить это реализовать.

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

(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).

(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