LINUX.ORG.RU
ФорумAdmin

Барахлит DNS на squd`e


0

0

Всем привет!

Вот какая проблема наблюдается: на сквидовой машине почему-то не запускается демон pdnsd, который необходим для функционирования кэширующего прокси-сервера, вот выводы прикси:

sudo /etc/init.d/pdnsd stop * Stopping pdnsd [ OK ]

sudo /etc/init.d/pdnsd start * Starting pdnsd [fail]

/etc/resolv.conf ---> http://dpaste.com/60358/

/etc/pdnsd.conf ---> http://dpaste.com/60360/

... и вот вывод с клиента, который из-за не работающего dns есссно глючит

proxychains layman -a crg ProxyChains-3.1 (http://proxychains.sf.net) * Running command "/usr/bin/rsync -rlptDvz --progress --delete --delete-after --timeout=180 --exclude="distfiles/*" --exclude="local/*" --exclude="packages/*" "rsync://rsync.cregion.ru/crg-overlay/" "/usr/local/portage/layman/crg""... |DNS-request| rsync.cregion.ru |S-chain|-<>-192.168.0.254:3128-<><>-4.2.2.2:53-<--timeout |DNS-response|: rsync.cregion.ru is not exist rsync: getaddrinfo: rsync.cregion.ru 873: Unknown error rsync error: error in socket IO (code 10) at clientserver.c(124) [receiver=3.0.5] * Failed to add overlay "crg". * Error was: Adding the overlay failed! Possible remains of the opration have NOT been removed and may be left at /usr/local/portage/layman/crg. Please remove them manually if required.

подскажите Хто может, что не так делаю?


... пожалуй ещё один вывод с прокси стоит добавить (для ясности)... 53-й порт...

netstat -apn | grep :53 tcp 0 0 192.168.0.254:53 0.0.0.0:* LISTEN 4992/named tcp 0 0 10.126.9.37:53 0.0.0.0:* LISTEN 4992/named tcp 0 0 127.0.0.1:53 0.0.0.0:* LISTEN 4992/named tcp6 0 0 :::53 :::* LISTEN 4992/named udp 0 0 0.0.0.0:53647 0.0.0.0:* 4966/avahi-daemon: udp 0 0 192.168.0.254:53 0.0.0.0:* 4992/named udp 0 0 10.126.9.37:53 0.0.0.0:* 4992/named udp 0 0 127.0.0.1:53 0.0.0.0:* 4992/named udp 0 0 0.0.0.0:5353 0.0.0.0:* 4966/avahi-daemon: udp6 0 0 :::53 :::* 4992/named

, где 192.168.0.254 - сквид

10.126.9.37 - провайдер

steven
() автор топика

1. Покажи логи после попытки запуска pdns.
2. Используй форматирование User line breaks или Preformatted text, иначе никто тебе помогать не будет.
3. Убунта - зло.

nnz ★★★★
()
Ответ на: комментарий от nnz

1. Покажи логи после попытки запуска pdns.

- #tail -f /var/log/squid/access.log - никаких видимых изменений после запуска pdnsd в этом логе нет!

Более того возник новый вопрос -

запускаю root@ubuntu:~# sudo /etc/init.d/pdnsd start * Starting pdnsd [fail] ... и тут же его останавливаю

root@ubuntu:~# sudo /etc/init.d/pdnsd stop * Stopping pdnsd [ OK ]

... и снова запускаю ...

говорит root@ubuntu:~# sudo /etc/init.d/pdnsd stop * Stopping pdnsd [ OK ]

2. Принял к сведению.

3. Каждому своё!

steven
() автор топика
Ответ на: комментарий от steven

Ну вот видишь, до чего тебя убунта довела. Ты даже не знаешь в какой лог смотреть. Если всю жизнь на ней сидеть будешь - из тебя разве что фиговенький вин-админ выйдет.

Обычно сообщения о демонов пишутся в dmesg и /var/log/daemon. Тебя интересуют сообщения об ошибках запуска pdnsd.

Еще кстати /etc/network/interfaces покажи.

nnz ★★★★
()
Ответ на: комментарий от nnz

Ну вот видишь, до чего тебя убунта довела. Ты даже не знаешь в какой лог смотреть. Если всю жизнь на ней сидеть будешь - из тебя разве что фиговенький вин-админ выйдет.

"Каждому своё..." - надпись над воротами концентрационного лагеря "Освенцим"...

Обычно сообщения о демонов пишутся в dmesg и /var/log/daemon. Тебя интересуют сообщения об ошибках запуска pdnsd.

Jun 27 23:29:06 ubuntu pdnsd[22578]: Could not bind tcp socket: Address already in use

Jun 27 23:29:06 ubuntu pdnsd[22578]: Could not bind to udp socket: Address already in use

Jun 27 23:29:06 ubuntu pdnsd[22578]: tcp and udp initialization failed. Exiting.

Еще кстати /etc/network/interfaces покажи

auto lo

iface lo inet loopback

steven
() автор топика
Ответ на: комментарий от steven

Е-мае.

Ты меня убил на месте.

Во-первых, у тебя в качестве днс-сервера уже запущен намед. Так что начни с
invoke-rc.d bind9 stop
update-rc.d -f remove bind9

Во-вторых, у тебя интерфейсами заведует networkmanager. На ноуте это еще ничего, но на сервере это ппц. Советую прописать интерфейсы в /etc/network/interfaces, иначе без гуя сети не будет. А гуй на сервере это тоже ппц. Гниете заживо, сударь!

nnz ★★★★
()
Ответ на: комментарий от nnz

Е-мае.

Ты меня убил на месте.

Извини, я не хотел! Честно!

Ты вот долго тут выражался на счет... и по поводу... а ведь что на мой взгляд отличает настоящего спец`А от псевдо... так это то что - настоящий - ответит как правильнее, а вот если спросят собственное мнение, то и его скажет! НО не наоборот! Разницу чуешь!? Хотя я на самом деле юзаю НЕ только Убунту... но и Дебиан, и Генту то же!... просто Всему своё время!...как гариццо - не спеша, но поспешаю...

Во-первых, у тебя в качестве днс-сервера уже запущен намед. Так что начни с invoke-rc.d bind9 stop ---> * Stopping domain name service...bind9 rndc: connect failed: 127.0.0.1#953: connection refused

update-rc.d -f remove bind9 ---> update-rc.d: /etc/init.d/remove: file does not exist однако я грохнул парочку пакетов bind9 и bind9utils

Во-вторых, у тебя интерфейсами заведует networkmanager. На ноуте это еще ничего, но на сервере это ппц. Советую прописать интерфейсы в /etc/network/interfaces, ---> а можно подробнее?

иначе без гуя сети не будет. А гуй на сервере это тоже ппц. Гниете заживо, сударь!... с твоей помощью надеюсь что процесс гниения преобразиццо в процесс преображения!... Заранее Мерси!

steven
() автор топика
Ответ на: комментарий от steven

Еще один ценный совет: цитаты из других сообщений лучше выделять знаком > в начале строки. И не забывай про user line breaks. Настроить дефолтный режим форматирования можно здесь http://www.linux.org.ru/edit-profile.jsp

>а можно подробнее?

Про настройку сети в Дебиане и производных хорошо рассказано здесь http://mydebianblog.blogspot.com/2008/04/blog-post_26.html

Из netstat в начале я увидел, что порт 53 у тебя слушает named, поэтому pdnsd не может начать его прослушивать. Однако
>Stopping domain name service...bind9 rndc: connect failed: 127.0.0.1#953: connection refused

слегка противоречит этому.
Поэтому покажи-ка еще раз netstat -nlp | grep 53

nnz ★★★★
()
Ответ на: комментарий от steven

Почитай "Справочник по Debian" ("Debian Reference"). В серверном плане убунта от него не отличается.

undertaker ★★
()
Ответ на: комментарий от steven

Да. Похоже у тебя намед с ума сошел :) rndc не слушает.

Ну тогда пристрели его
killall -9 named

и попробуй запустить pdnsd.

nnz ★★★★
()
Ответ на: комментарий от steven

Ну это не факт что pdns у тебя правильно настроен :)

А сохранять там ничего не надо. Учитывая что ты очень резво грохнул bind9 - вряд ли теперь намед сможет запуститься :) Только убедись, что у тебя pdnsd в автозапуск прописан. Должен быть симлинк вроде /etc/rcS.d/Sдвецифрыpdnsd, указывающий на скрипт /etc/init.d/pdnsd.

nnz ★★★★
()
Ответ на: комментарий от nnz

>Ну это не факт что pdns у тебя правильно настроен :)

так вот он в каком виде и есть --> http://dpaste.com/60360/ глянь пож-ста вроде всё по инструкции делал http://www.f0x.ru/2008/06/dns-proxy-ubuntu_18.html а уж хороша, иль плоха ли инструкция - просьба так же заценить!?

>Только убедись, что у тебя pdnsd в автозапуск прописан. Должен быть симлинк вроде /etc/rcS.d/Sдвецифрыpdnsd, указывающий на скрипт /etc/init.d/pdnsd.

Убедился...есть! ---> /etc/rcS.d/S39pdnsd

Что-то ещё необходимо подкрутить!?... или дальше только в конфиге может быть дело!?... потому как клиентская машина с Генту выдаёт по прежнему - http://dpaste.com/60504/

steven
() автор топика
Ответ на: комментарий от steven

Черт его знает насколько оно правильно. Эту хреновину настраивать еще не не приходилось. И с proxychains не работал (предпочитаю dante).

Для диагностики прежде всего покажи /etc/resolv.conf с клиентской машины. Там в начале должна быть строчка
nameserver айпишник_прокси

Попробуй сделать dig ya.ru с клиентской машины. Если выдаст ошибки - проверь, может, у тебя 53 порт фаерволом закрыт.

Аналогично на самом сервере - в начале /etc/resolv.conf должна быть строчка nameserver 127.0.0.1 и dig ya.ru должен работать.

nnz ★★★★
()
Ответ на: комментарий от nnz

>Попробуй сделать dig ya.ru с клиентской машины.

# dig ya.ru

; <<>> DiG 9.4.3-P2 <<>> ya.ru ;; global options: printcmd ;; connection timed out; no servers could be reached - и что вот эта фраза означает, что серверы недоступны!?... а пинг то есть до прокси!

>Если выдаст ошибки - проверь, может, у тебя 53 порт фаерволом закрыт.

#/etc/init.d/iptables stop bash: /etc/init.d/iptables: Нет такого файла или каталога

>Аналогично на самом сервере - в начале /etc/resolv.conf должна быть строчка nameserver 127.0.0.1 и dig ya.ru должен работать.

http://dpaste.com/60512/ - с прокси! ну тут вроде понятно!... всё наладилось...

steven
() автор топика
Ответ на: комментарий от steven

Ни черта не наладилось.

Во-первых, почему у тебя в конфиге pdns прописан 10.5.0.2, хотя правильным днс-сервером, судя по выводу dig, является 10.5.3.2?

Во-вторых, почему dig спрашивает не у 127.0.0.1, а у провайдерского днс? nameserver 127.0.0.1 в начале /etc/resolv.conf есть?

В-третьих, в Дебиане дурак-мейнтейнер грохнул init-скрипт для iptables из-за багов в совершенно другой программе - iptables-save. В убунте естественно этот эпический косяк никто и не подумал исправить. Так что iptables там открывается командами
iptables -F
iptables -P INPUT ACCEPT
iptables -P FORWARD ACCEPT
iptables -P OUTPUT ACCEPT

>и что вот эта фраза означает, что серверы недоступны!?... а пинг то есть до прокси!

В resolv.conf клиента сервер прописан???

nnz ★★★★
()
Ответ на: комментарий от nnz

>Во-первых, почему у тебя в конфиге pdns прописан 10.5.0.2, хотя правильным днс-сервером, судя по выводу dig, является 10.5.3.2?

Оба IP являются IP-адресами DNS провайдера!

>Во-вторых, почему dig спрашивает не у 127.0.0.1, а у провайдерского днс? nameserver 127.0.0.1 в начале /etc/resolv.conf есть?

В самой первой строке на проксе в /etc/resolv.conf - указан nameserver 127.0.0.1

>...iptables там открывается командами... а есть вот такой вывод о текущем состоянии в Ебунте...

#iptables -L

Chain INPUT (policy ACCEPT) target prot opt source destination

Chain FORWARD (policy ACCEPT) target prot opt source destination

Chain OUTPUT (policy ACCEPT) target prot opt source destination

>В resolv.conf клиента сервер прописан???

Да прописан!

nameserver 192.168.0.254 domain 211.ru search 211.ru nameserver 10.5.0.2 nameserver 10.5.3.2

И вот ещё один вывод - http://dpaste.com/60538/

steven
() автор топика
Ответ на: комментарий от steven

Так. Прежде всего снова посмотри netstat -nlp | grep 53 на серваке - может там pdnsd отвалился.

Потом посмотри iptables -t nat -vnL там же. Может, там редирект с 53 порта идет.

Еще попробуй dig @127.0.0.1 ya.ru с сервера и dig @192.168.0.254 ya.ru с клиента.

nnz ★★★★
()
Ответ на: комментарий от steven

Значит pdnsd таки лежал? :)

>Вот только как быть с http://dpaste.com/60549/ ? - где сказано, что открыто, НО не работает!

Что именно не работает? open|filtered - это нормальный ответ для открытого udp-порта.

nnz ★★★★
()
Ответ на: комментарий от nnz

>Значит pdnsd таки лежал? :)

Да, я его сам же рубанул а потом таки и вспомнил... ,что неплохо бы и вГлючить! А то не будет работать! Машину на всякий случай перегрузил... всё шевелиццо, тока теперича и сквида и pdnsd которые во время запуска почему-то не хотят корректно запускаццо - есть подозрение на НЕ те уровни запуска!?... приходиццо активировать после окончания всех процессов!

>Что именно не работает? open|filtered - это нормальный ответ для открытого udp-порта.

Хочешь сказать что у него просто open не быват!? Хорошо, коли так! А не работает на клиенте всё тот же оверлей на генту...

http://dpaste.com/60558/

или так http://dpaste.com/60562/

Собственно с чего вся бадяга и началась...

И ещё если есть возможность чиркни свой jabber или gmail пообщаться... до скорой связи!

И ЕЩЁ раз Благодарствуйте! ;-)

steven
() автор топика
Ответ на: комментарий от steven

Насколько я понял, косяк происходит из-за того, что proxychains заворачивает DNS-запросы в туннель. А они этого очень не любят. DNS работает в основном через udp, а его через сквид точно проксировать нельзя :) Скорее всего косяк в настройках proxychains.

>Хочешь сказать что у него просто open не быват!?

Просто open - у tcp. Ему послали syn, он ответил syn/ack - значит open. Не ответил - filtered. Ответил rst - closed. А в udp таких формализмов нету. Если ответит icmp-port-unreachable - значит closed. Не ответит - хз, может и open, а может, и filtered.

>И ещё если есть возможность чиркни свой jabber или gmail пообщаться... до скорой связи!

whois nnz1024-ripn

nnz ★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.