|
|
ru.linux- RU.LINUX --------------------------------------------------------------------- From : Alexandr Goncharov 2:5020/400 15 Oct 2002 09:50:58 To : Valentin Nechayev Subject : Re: pdnsd -------------------------------------------------------------------------------- net.ru> <aoe1n2$1em9$1@horse.lucky.net> From: Alexandr Goncharov <agv@tomsknet.ru> Valentin Nechayev <netch@segfault.kiev.ua> wrote: >>>> Alexandr Goncharov wrote: VN>>> Hасчет развесистости верю. Прошу доказать правильность. VN>>> Доказательство должно учитывать содержание kill(2) manpage о правах VN>>> для доставки сигналов. AG>> man named учит нас, что: AG>> SIGNALS AG>> In routine operation, signals should not be used to con- AG>> trol the nameserver; rndc should be used instead. VN> Почему? Мне неинтересно, что там в man named. VN> Меня интересует, почему Вагнер считает rndc более правильным методом VN> настолько, чтобы исключать сигналы. Я, собственно, не на эти строки хотел обратить внимание, а на набор сигналов, которые остались. И то, как они обрабатываются. За Вагнера не скажу, но мне тоже кажется нынешний метод более правильным. Хотя бы из тех соображений, что если сигнал не перехватить и не обработать, то единственное действие, которое он произведет с процессом - убьет его. Во-вторых, имеется тенденция засовывать bind в chroot, пускать его не от root-а, а от бесправного юзера и т.д. Если ориентироваться на сигналы, то тут же надо вспоминать, что не-root может послать сигнал только принадлежащим ему процессам. Т.е. человек, управляющий сервером, должен будет (возможно) менять себе uid/euid и т.д. В то время, как использование канала правления освобождает от этих зависимостей. К тому же, канал управления создавался, скорее всего, не для того, чтобы избавиться от сигналов. А для обеспечения возможности удаленного управления и обеспечения всех потребностей в управлении. А раз уж создали - зачем дублировать его функции еще и обработчиками сигналов? VN>>> А ну-кось, метод чтения кэша с диска и записи его на диск в пригодном VN>>> для чтения формате - в студию. .... VN> Угу. И надо еще учитывать, что кэш хранит не только значения, но и данные VN> об их происхождении, которые просто незаменимы при разборах сложных полетов. Кстати, что имелось в виду под записью на диск в пригодном для чтения формате? Чтение человеком? Я, признаться, не помню уже, в каком виде прежние версии кэш на диск сбрасывали. Hо то, что вижу сейчас - вполне читабельно. Или это о другом? AG>> Правда, есть еще мысль, что при наличии возможности ведения разных view, AG>> наличия rndc flush [view], возможности перечитывания конфигурации AG>> потребность в остановках сервера (а следовательно - потребность в подгрузке AG>> кэша) резко снизилась. Если не сказать, что устремилась к нулю. VN> Whom how. Мне функциональность по подгрузке кэша и расширение возможности VN> задачи чего-то в hints file на ряде хостов была бы крайне полезна... Кто бы спорил. Hо полезна - не значит необходима. VN> /netch -- Alexandr V. Goncharov, | Digital Networks, Tomsktelecom AGV-RIPE, | agv@tomsknet.ru AGV3-RIPN | phonе: +7(382-2)662510 --- ifmail v.2.15dev5 * Origin: Tomsktelecom - Digital Networks (2:5020/400) Вернуться к списку тем, сортированных по: возрастание даты уменьшение даты тема автор
Архивное /ru.linux/1223286056caf.html, оценка из 5, голосов 10
|