ALT Linux Bugzilla – Full Text Bug Listing
| Summary: | bind перестаёт работать с интерфейсом после ifup/ifdown | ||
|---|---|---|---|
| Product: | Sisyphus | Reporter: | Anton Farygin <rider> |
| Component: | bind | Assignee: | placeholder <placeholder> |
| Status: | CLOSED FIXED | QA Contact: | qa-sisyphus |
| Severity: | normal | ||
| Priority: | P3 | CC: | aen, asy, evg, george, glebfm, jenya, ldv, mike, placeholder, rider, sbolshakov, sem, slev |
| Version: | unstable | ||
| Hardware: | all | ||
| OS: | Linux | ||
|
Description
Anton Farygin
2017-03-29 20:55:59 MSK
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 |
