11.29 Когда я использую имя пользователя и пароль, я не имею доступа к некоторым файлам.

Когда я пытаюсь получить доступ к

ftp://username:password@ftpserver/somewhere/foo.tar.gz

Я получаю

somewhere/foo.tar.gz: Not a directory.

Используйте такой URL вместо этого:

ftp://username:password@ftpserver/%2fsomewhere/foo.tar.gz

11.30 PingerOpen: icmp_sock: (13) Permission denied

Это значит, что ваша программа pinger не имеет рутовых привелегий. Вам необходимо делать следующее:

% su

# make install-pinger

или

# chown root /usr/local/squid/bin/pinger

# chmod 4755 /usr/local/squid/bin/pinger

11.31 Что такое петля передачи ?

Петля передачи - это когда запрос проходит через прокси более чем один раз. Петля передачи может возникнуть, если:

• кеш посылает запрос самому себе. Это может произойти при настроенном прозрачном проксировании (или в режиме ускорителя).

• пара или группа кешей передают запросы друг другу. Это может произойти, когда Squid использует ICP, Cache Digests или базу даннх ICMP RTT для определения ближайшего кеша.

Петля передачи обанруживается путем проверки заголовка Via в запросе. Каждый кеш, который "прикоснулся" к запросу, должен добавить имя своего хоста в заголовок Via. Если кеш заметит имя собственного хоста в этом заголовке для входящего запроса, то он определит, что где-то имеет место петля передачи.

ЗАМЕЧАНИЕ: Squid может сообщать о петле передачи, если запрос прошел через два кеша, которые имеют одинаковое значение visible_hostname. Если вы хотите, чтобы у вас были несколько машин с одинаковыми visible_hostname, то вы должны присвоить каждой машине отличное оот других unique_hostname, чтобы петли передачи определялись корректно.

Когда Squid обнаруживает петлю передачи, он вносит запись об этом в файл cache.log вместе с полученным заголовком Via. По этому заголовку вы можете определить какой кеш (последний в списке) направил запрос к вам.

Один из способов уменьшить частоту появления петель передачи - сменить тип взаимодействия с parent на sibling.

Другой способ - использование правил cache_peer_access. К примеру:

# Наши родительские кеши

cache_peer A.example.com parent 3128 3130

cache_peer B.example.com parent 3128 3130

cache_peer C.example.com parent 3128 3130

# Список ACL

acl PEERS src A.example.com

acl PEERS src B.example.com

acl PEERS src C.example.com

# Предотвращение петель передачи

cache_peer_access A.example.com allow !PEERS

cache_peer_access B.example.com allow !PEERS

cache_peer_access C.example.com allow !PEERS

Описанная выше конфигурация указывает squid-у НЕ передавать запросы родительскому кешу A, B, или C, когда этот запросы был получен с одного изи них.

11.32 Accept failure: (71) Protocol error

Это сообщение в основном характерно для систем Solaris. Mark Kennedy дает хорошее пояснение этому:

Error 71 [EPROTO] - неявный способ сообщить, что сервер получил запрос от клиента на входящее TCP-соединение, но клиент разорвал соединение до того, как сервер смог принять его. Т.е. ваш сервер игнорировал клиентов слишком долго. Мы наблюдали подобное, когда у нас кончались файловые дескрипторы. Я предполагаю, что это также может случится, если заблокирован squid по какой-то причине ждлительное время.