Static linked у меня _нормально_ не получилось :( проблема в libc.a (Debian 2.0 и RedHat6.0) -

libc.a :

symbol __res_randomid already reference in libbind.a

Покывырявшись в сорцах удалось скомпилять-таки... :))

у меня static тоже не сработало где коврял? 

Если порыться в сорцах на предмет __res_randomid, то видно, что функция используется в /lib/res_init.c и в /lib/res_data.c и более нигде: описана в res_init.c, а используется в res_data.c. Да и еще в resolv.h. Вообщем правим res_init.c на предмет этого символа: __res_randomid_2 ну и везде где надо еще: resolv, res_data. Компилим - ОК! А еще можно выкинуть этот symbol из resolv.h. Тогда res_data будет юзать этот symbol из libc.a. Все.

товарищ сэндман, пожалуйста, объясните непонятливому что же конкретно надо поправить в этой функции res_randomid, которая описана в res_init.c KiNS. kins@fcom.ru буду очень признателен за информацию

Блин! Ну устраните конфликт имен!
Просто переименуй ее в модуле res_init.c! И ссылки на нее в res_data.c и
в resolv.h соответсвенно!

Если не трудно, то объясните, зачем запускать named с chroot? Разве недостаточно запустить его под пользователем и группой, не имеющего ни к чему доступ? named -u named -g named Почему это небезопасно?

ну видиш ли ежели ктото сможет поиметь твой диск под обыкновенным юзером то рано или поздно он же его поимеет и под рутом локальных то дыр не меньше сетьевых :-(

А если обыкновенного юзера зовут ноубоди ноугроуп?

А почему получается так:

Запускаю named -u named -g named. После этого смотрю владельца процессов - команда ps показывает, что процесс named имеет владельца named. Но когда смотрю юзеров, владеющим сокетами и файлами командой lsof, то обнаруживаю, что сокет слушает все же root. В статье говорилось, что должен быть named. Почему так?

А часом inetd не обслуживает 53-ий порт??

Нет, совершенно точно нет

Потому что inetd у меня вообще остановлен. Я смог добиться, что сокет слушает пользователь named только в одном случае - если я логинюсь как пользователь named и из под него запускаю сам демон named, тогда действительно lsof показывает, что пользователь named слушает сокет, но в таком режиме демон не работает правильно - возникают ошибки о недостаточности прав на доступ к сокету и в результате порт 53 не отвечает. При этом, если я запускаю его из под root: named -u named -g named, в messages указывается, что named запущен с user = named и group = named, но lsof это не подтверждает. Вопрос к тем, кто chroot-нул - у вас lsof что показывает?

Совершенно точно bind (у меня под этим userом)
#lsof -i |grep named
named 127 bind 3u inet 0x02cf5810 0t0 UDP *:1025
named 127 bind 20u inet 0x02cf5c0c 0t0 UDP localhost:domain
named 127 bind 21u inet 0x03404018 0t0 TCP localhost:domain (LISTEN)
named 127 bind 22u inet 0x03404414 0t0 UDP myhost.mydomain.net:domain
named 127 bind 23u inet 0x03404810 0t0 TCP myhost.mydomain.net:domain (LISTEN)

Система на Debian 2.0
Стартую так:
start-stop-daemon --start --quiet --exec \
/chroot/named/usr/sbin/named -u bind \
-g bind -t /chroot/named

Тебе повезло

На самом деле ситуация такая. У меня два Линуха - Mandrake 5.2 (2.0.36) и Mandrake 7.0. (2.2.14). Так вот на "боевой" машине, с 2.2.14 named упорно не хочет запускаться как надо, точнее запускается, но lsof это не подтверждает, а на старой версии 2.0.36 все работает как надо! На ней сокеты слушает пользователь, указанный в named -u <юзер>. Прямо хоть на старую версию переходи. Может там какая фича дополнительная есть, чтобы позволять сокеты слушать кому угодно. Если кто знает, подскажите.