Очередная задачка для сисадминов

[dil]

Линуксовый сервер. Очень секьюрный, типа. Под CentOS, хотя это не принципиально. На него только что водрузили squid из стандартного RPM’а, настроили access list’ы, запустили.

Подключаемся из клиентского браузера, идём на www.google.com… Squid думает минуты полторы, после чего выдаёт страницу с сообщением, что не может определить адрес Гугла.

Офигеваем. Заходим на сервер по ssh, запускаем sudo bash, проверяем /etc/resolv.conf — всё нормально, указаны действующие NSы. В nsswitch.conf для hosts тоже всё нормально: files dns.

ping www.google.com — работает. wget — работает. squid — не работает. На всякий случай перезапускаем. Всё равно не работает. Пробуем ходить через него на другие сайты, браузером с клиентской машины, локально телнетом, всё одно: думает минуты полторы, потом говорит, что не может отресолвить имя.

И как вы думаете, что это были за грабли?

Оригинал этой записи в личном блоге.

Comments

[alexkuklin]

SELinux?

[dil]

Не-а. Выключен нафиг.

[alexkuklin]

chroot?

[dil]

Не. В центосе, кажется, только bind умеет из коробки в chroot'е работать. Squid работает в настоящем корне.

[alz421]

> запускаем sudo bash, проверяем /etc/resolv.conf

Зачем подсказываешь? :))))

[filonovd.myopenid.com]

resolv.conf не читается от остальных юзеров? Не интересно. :(

[dil]

Зато совершенно неожиданно.

[filonovd.myopenid.com]

не, мне было ожиданно (может потому, что наступал на эти или подобные грабли раньше) и потому показалось, что такая "ошибка" не стоит упоминания. Хотя, наверное, в первый раз оно забавляет, да.

[dil]

Только это была не ошибка. Это было сделано намеренно. Для "повышения секьюрности". Типа, чтоб враги ни в коем случае не узнали, где у нас тут DNSы. Но с тех пор, как это делали, всё уже забыли, поэтому получились такие грабли.

[dil]

Ничего не подсказываю, говорю всё, как было

[alz421]

Дык sudo bash ведь явно неспроста перед чтением resolv.conf. Это ж не /etc/shadow какой-нибудь :)

У меня раз интереснее было - некие умельцы сделали chmod 0400 /etc/nsswitch.conf, предположи, в какой ситуации оно создало грабли? :)

[dil]

Ну как бы от простого пользователя ни логи посмотреть, ни конфиг сквида поправить, поэтому первым делом всё равно sudo. А это оказалось существенно.

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

[starcat13]

а dns_nameservers в squid.conf случайно не выставлены в что-то левое?

[dil]

Случайно нет. Этой директивы вообще нет.

[sewa]

apparmor ?

[dil]

Нету. Я вообще не уверен, что он в редхатах применяется, там до сих пор selinux, но он выключен.

[rblaze.livejournal.com]

Ваша проблема в том, что вы слишком много думаете, а надо трясти. tcpdump и strace решают такие непонятки на ура -)

[dil]

strace на squid - это то ещё удовольствие. А tcpdump я пробовал. Тишина. То есть, полная.

[rblaze.livejournal.com]

Воот! Тишина - значит запросы не уходят, их никто не отправляет. Кстати, надо было еще loopback проверить, по умолчанию-то туда фигачится, насколько я помню. Ну а дальше strace и grep по всем возвратам с ошибкой.

[dil]

Нет, в lo тоже ничего нету. Ну да, получается, что запросов никто не отправляет. А почему??

[rblaze.livejournal.com]

strace | grep по ошибкам, смотрим ошибки, видим EPERM на resolv.conf. Неудачных вызовов в логе будет не так уж много.

[dil]

Ага, угадал :)

[rblaze.livejournal.com]

Чего гадать, там выше уже кто-то ответ написал :)