Имеем: bind-9.10.4-alt2 пачку vpn туннелей в разные стороны (openvpn). форвардинг запросов dns через vpn туннели к другим named серверам. Проблемы: bind перестаёт отправлять forward запросы на другой сервер, если интерфейс VPN переинициализируется по каким-то причинам (аналог ifdown && ifup) после перезапуска bind снова начинает работать нормально. Явно это из-за сброса capability. Меня бы устроила ручка по отключению такого поведения, ну или какое-то исправление, которое позволило бы bind садиться на те интерфейсы, которые появились после его запуска. Аналогичная проблема с dhcp, но там не vpn а vlan'ы - после ifdown/ifup на интерфейсе приходится перезапускать dhcp сервер.
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
