Настроить squid на работу с parent proxy
в комплекте со сквидом поставляется squid.conf с очень подробными комментариями
есть очень хороший FAQ и прочая документация на www.squid-cache.org
Как сабж по-английски называется в терминологии squid и того FAQ'а ? А то там ДОФИГА всего.
комментарии в squid.conf ты прочитать обязан
Прочитал.
Проще взять готовое решение и проанализировать его структуру, чем перечитывать тонну манов. Я же спросил не как стать мега отцом по настройке SQUID'а, а всего лишь разъяснить одну настройку, которая в не-линуксовых проксях делается очень легко и интуитивно.
и это я вымучивал целых 4 поста!
кто ж знал, что ты больше чем на одну ссылку кликать не умеешь...
с таким подходом форум hard'n'soft можно вообще закрыть. Ведь всё есть в гугле.
может ты не знаешь, что такое hierarchy?
да, и если бы все заглядывали в гугл, число вопросов в hard'n'soft уменьшилось бы на порядок
PS Но в этом случае ответ в конечном итоге дан был
Всё в твоих руках. Будешь банить всех, кто задает вопросы в HS. Начни с меня.
Если Вы соизволите внимательно прочитать мой пост , то поймёте , что я не против тех кто задаёт вопросы , ибо сам такой . Я только сказал "Если появилось желание сказать "Go google" , подумай , этот форум не только ля таких крутых как ты" .
а то бы революцию тут устроил
теперь смотрим на результат:
таки получил, что хотел
а я так и не узнал, что же помешало ему найти ответ в документации
лень читатать столько инфы на английском
а я надеялся на что-то интересное
ЗЫ Если я ошибаюсь -то поправьте меня пожалуйста ...........
# TAG: cache_peer
# To specify other caches in a hierarchy, use the format:
#
# cache_peer hostname type http_port icp_port
#
# For example,
#
# # proxy icp
# # hostname type port port options
# # -------------------- -------- ----- ----- -----------
# cache_peer parent.foo.net parent 3128 3130 [proxy-only]
# cache_peer sib1.foo.net sibling 3128 3130 [proxy-only]
# cache_peer sib2.foo.net sibling 3128 3130 [proxy-only]
#
# type: either 'parent', 'sibling', or 'multicast'.
#
# proxy_port: The port number where the cache listens for proxy
# requests.
#
# icp_port: Used for querying neighbor caches about
# objects. To have a non-ICP neighbor
# specify '7' for the ICP port and make sure the
# neighbor machine has the UDP echo port
# enabled in its /etc/inetd.conf file.
#
# options: proxy-only
# weight=n
# ttl=n
# no-query
# default
# round-robin
# multicast-responder
# closest-only
# no-digest
# no-netdb-exchange
# no-delay
# login=user:password | PASS | *:password
# connect-timeout=nn
# digest-url=url
# allow-miss
# max-conn
#
# use 'proxy-only' to specify that objects fetched
# from this cache should not be saved locally.
#
# use 'weight=n' to specify a weighted parent.
# The weight must be an integer. The default weight
# is 1, larger weights are favored more.
#
# use 'ttl=n' to specify a IP multicast TTL to use
# when sending an ICP queries to this address.
# Only useful when sending to a multicast group.
# Because we don't accept ICP replies from random
# hosts, you must configure other group members as
# peers with the 'multicast-responder' option below.
#
# use 'no-query' to NOT send ICP queries to this
# neighbor.
#
# use 'default' if this is a parent cache which can
# be used as a "last-resort." You should probably
# only use 'default' in situations where you cannot
# use ICP with your parent cache(s).
#
# use 'round-robin' to define a set of parents which
# should be used in a round-robin fashion in the
# absence of any ICP queries.
#
# 'multicast-responder' indicates that the named peer
# is a member of a multicast group. ICP queries will
# not be sent directly to the peer, but ICP replies
# will be accepted from it.
#
# 'closest-only' indicates that, for ICP_OP_MISS
# replies, we'll only forward CLOSEST_PARENT_MISSes
# and never FIRST_PARENT_MISSes.
#
# use 'no-digest' to NOT request cache digests from
# this neighbor.
#
# 'no-netdb-exchange' disables requesting ICMP
# RTT database (NetDB) from the neighbor.
#
# use 'no-delay' to prevent access to this neighbor
# from influencing the delay pools.
#
# use 'login=user:password' if this is a personal/workgroup
# proxy and your parent requires proxy authentication.
# Note: The string can include URL escapes (i.e. %20 for
# spaces). This also means that % must be written as %%.
#
# use 'login=PASS' if users must authenticate against
# the upstream proxy. This will pass the users credentials
# as they are to the peer proxy. This only works for the
# Basic HTTP authentication sheme. Note: To combine this
# with proxy_auth both proxies must share the same user
# database as HTTP only allows for one proxy login.
# Also be warned that this will expose your users proxy
# password to the peer. USE WITH CAUTION
#
# use 'login=*:password' to pass the username to the
# upstream cache, but with a fixed password. This is meant
# to be used when the peer is in another administrative
# domain, but it is still needed to identify each user.
# The star can optionally be followed by some extra
# information which is added to the username. This can
# be used to identify this proxy to the peer, similar to
# the login=username:password option above.
#
# use 'connect-timeout=nn' to specify a peer
# specific connect timeout (also see the
# peer_connect_timeout directive)
#
# use 'digest-url=url' to tell Squid to fetch the cache
# digest (if digests are enabled) for this host from
# the specified URL rather than the Squid default
# location.
#
# use 'allow-miss' to disable Squid's use of only-if-cached
# when forwarding requests to siblings. This is primarily
# useful when icp_hit_stale is used by the sibling. To
# extensive use of this option may result in forwarding
# loops, and you should avoid having two-way peerings
# with this option. (for example to deny peer usage on
# requests from peer by denying cache_peer_access if the
# source is a peer)
#
# use 'max-conn' to limit the amount of connections Squid
# may open to this peer.
#
# NOTE: non-ICP neighbors must be specified as 'parent'.
#
#Default:
cache_peer proxy.relline.ru sibling 3128 3130
а оно надо?
поэтому я стараюсь показать, как можно самостоятельно решать такие вопросы
получается плохо
дай линк на фак где пишется как в море информации быстро находить нужную информацию.
а здесь всего-то надо было в оглавлении руководства найти ссылку на ответ
в оглавлении около 3х страничек, нужная ссылка находится очень близко к началу, так как это одно из самых элементарных действий
Я просто заметил, что на вопросы типа "Почему упал и не встаёт эксчендж", "Как настроить pptp под линух" я нахожу ответы во много раз дольше, чем другие. Вот и вопрос почему у одних получается найти ответ за час, а у меня за неделю.
а чем ты готов пожертвовать, чтобы научиться находить ответы за час вместо недели?
многим
тогда начинай ботать
я правильно тебя понял?
это да, но почему-то другим людям требуется меньше времени, чтобы научиться при той же интенсивности обучения. Что-то я делаю не так, значит.
Ксати, насчет squid.conf- там дофига параметров, которые нормально не описаны, ни в документации, ни в FAQ, например, разница между ICP и HTCP, так что бывает приходится задавать вопрос в рассылке или спрашивать напрямую у Отцов, что как показывает практика быстрее, чем разбираться в рассылке...
с таким подходом форум hard'n'soft можно вообще закрыть. Ведь всё есть в гугле.ДА!
правда в ветку 3.0 я не смотрел - а там эти чудики на C++ всё переписывают, и наверное уже хрен что поймёшь, так как писать на C++ гораздо труднее
а может просто недостаточно времени уделяешь
грамотный педагог нужен, чтобы понять
Исходник в Squid действительно очень хорошо читабельный, однако, опять вспомню пример ICP и HTCP, понять из него плюсы применения того или иного метода в разных случаях крайне тяжело. Гораздо проще и с точки зрения времени и понимания, действительно спросить это у отцов, которые работают с этим годами...
>а я надеялся на что-то интересное
Вообще говоря, я с самого начала спросил :
Это с помощью peer_cashe делается?
Чего проще было ответить - "да"? Это бы заставило меня более тщатильно изучить использование этого параметра.
Т.к. был дан совет перечитать документацию, я сделал вывод что не верно использовать для этого peer_cashe , и существует что-то более магическое. Тем более, строчку с этим параметром в составленном мною squid.conf сервер просто игнорировал, и лез на сайт прямо (объяснение этому факту я нашел позднее в User Guide).
Кроме peer_cashe ничего походего в ФАКе я не нашел, поэтому и стал спрашивать дальше.
Твоя позиция понятна: я сам все всё разрюхал в настройках линукса, значит, вы можете сделать то же самое.
2 :
"TAG: cache_peer
# To specify other caches in a hierarchy, use the format:"
Не очевидно, что под этим имеется в виду то, что в виндовых прокси называется "parent proxy". Дальше в тексте фигурируеть слово "cache", а то что я искал (в моем понимании) называлось proxy-server.
Найди отличие между формулировками
- иди читай документацию, кретин
- ответ в google
- ответ можно найти тут
- ответ - вот: ...
мои личные проблемы помешали
в частности, связанные с тем, что ты переврал название параметра
"cache_peer" и "peer_cashe" - разные строчки мне вот разница сразу в глаза бросается, а ты употребляешь разные написания в одном и том же тексте
> Твоя позиция понятна: я сам все всё разрюхал в настройках линукса, значит, вы можете сделать то же самое.
Нет! Ни в коем случае, утверждать так было бы негуманно.
Кроме того, сквид и линукс весьма слабо связаны, похоже, виндовому порту уделяется гораздо больше внимания, судя про трафику в рассылке
Стивенс не нравится? есть ещё http://book.itep.ru/
>в частности, связанные с тем, что ты переврал название параметра
>"cache_peer" и "peer_cashe" - разные строчки мне вот разница сразу в глаза бросается, а ты употребляешь разные написания в одном и том >же тексте
Ну тогда бы и сказал про это сразу!
Просто (это не оправдание, но все же) в произношении слова cache слышится "ш", поэтому машинольно было написано неправильно.
> Твоя позиция понятна: я сам все всё разрюхал в настройках линукса, значит, вы можете сделать то же самое.
>Нет! Ни в коем случае, утверждать так было бы негуманно.
А как гуманно?
Если точно известно, что его там нет - аналогично.
А вот заставлять человека самому убеждаться, что ответа нет, и никто его не знает (я не про этот случай, естественно когда сам уже проделал это - негуманно
Априори ясно, Глеб, что ответ на такой простой вопрос скрыт в документации или гайде. Поэтому просто давать ссылку на UserGuide бессмысленно.
Моя проблема заключалась в том, что я не знал, как на английском выглядит объект моего поиска.
Вообще говоря, я считаю, что тебе даже не следовало сюда писать. Ответ на твой вопрос за 5 секунд ищется в Гугле (я не буду сейчас этого проверять, основываясь на полученном опыте, да и об этом я уже неоднократно писал).
Но раз уже ты написал, то в дело вступает вопрос об эффективности и о скорости получения результата. По сути, одно и тоже, в данном случае. Вместо того, чтобы пытать человека, который, возможно, был занят какими-нибудь важными делами, ты мог бы найти ответ на свой вопрос прямо в конфигурационном файле. Или в файле руководства, что еще проще.
Тем самым, упорством ты не только оттянул получение ответа, но и отвлек многих людей. Мне это только в радость, повод попиздеть, а у кого-то, возможно, курсовая горит или еще какой пиздец.
Задумайся над этим.
ответил бы, скорее всего: "cache_peer" и всё, а ещё более вероятно, что продолжал бы заниматься важным делом, и дал бы ответить другим
Вообще говоря, я считаю, что тебе даже не следовало сюда писать. Ответ на твой вопрос за 5 секунд ищется в Гугле (я не буду сейчас этого проверять, основываясь на полученном опыте, да и об этом я уже неоднократно писал).
Но раз уже ты написал, то в дело вступает вопрос об эффективности и о скорости получения результата. По сути, одно и тоже, в данном случае. Вместо того, чтобы пытать человека, который, возможно, был занят какими-нибудь важными делами, ты мог бы найти ответ на свой вопрос прямо в конфигурационном файле. Или в файле руководства, что еще проще.
Дело в том, что я потратил довольно много времени, чтобы найти ответ на вопрос самомтоятельно (в том числе через гугл). Гораздо больше, чем те 5 секунд, которые бы понадобились тебе (если тебе понадобилось 5 секунд, то про милисекунды, которые я бы занял у 16.10 я вообще молчу) . Так что твоя гипотеза про эффективности не верна.
Тем самым, упорством ты не только оттянул получение ответа, но и отвлек многих людей. Мне это только в радость, повод попиздеть, а у кого-то, возможно, курсовая горит или еще какой пиздец.
Задумайся над этим.
Задумайся, не пора ли тебе вставить эту фразу (паттерн?) в подпись.
Можно пойти путем выявления ценностей, калибровки, хуёвки.
Можно подружиться с ним и за годы дружбы помочь ему измениться.
А можно просто гиперболировать всё сразу. Так проще.
Если я правильно тебя понял, то обычно я так и делаю
Все-таки не всегда стоит делать именно так, показывает, что на некоторый вопрос можно очень быстро получить элементарный ответ, не заморачиваясь...
Поэтому гораздо правильнее использовать для цитирования тег [ quote ], который тут есть.
Я же сказал, что не хочу сегодня говорить про Гугл.
А те ссылки, которые тебе сразу дали, должны были принести быстрый результат.
Достаточно посмотреть, что получается, когда кто-то просит посоветовать конфигурацию компа
Как правильно
Исторически сложилось, что Яндекс работает быстрее любого, кто может прочитать и ответить на вопрос. Думаю, что даже быстрее, чем Головорез может прочитать.
Исторически сложилось, что Яндекс работает быстрее любого, кто может прочитать и ответить на вопрос. Думаю, что даже быстрее, чем Головорез может прочитать.
Хм. Правильный ответ только на 9ом месте, и то не очевидно, что он правильный, если его не знать заранее. Маза яндекс сосёт )
Oops ! в нашей общаге, вроде нет, так что в данном случае все же получить Holy War по поводу сквида, все же гораздо менее вероятно, чем например, в том же случае с программами для резки CD.
Сторонников
Маза нужно хитрость знать. Яндекс сосёт в том плане, что не умеет на вопросы отвечать. Так что надо искать ответ, а не вопрос задавать, конечно.
Слушай, , почему ты почти никогда не задаешь вопросы, ни в Network, ни тут?
Всё-таки IMHO надо и тебе немного пересмотреть свои советы.
Кстати, надо бы сделать агитплакаты вроде "Гугл рулит". С профилями отцов.
Понимаешь, дело в том, что я понимаю, что получить ответ на свой вопрос,если он у меня появляется, ни здесь, ни в Network-e, в течении приемлимого времени нет. А простые вопросы, я как-то сам привык уже решать .
Помоги мне доступно объяснить всем, что нужно делать именно так. Простые вопросы решать самим.
Проблема в том, что не все имеют такие базовые знания,в области IT, такие как у тебя, Anonymous-a (192.168.16.10 ну и скромно добавлю себя в этот список.
Боюсь, ты слишком высокого мнения о моих знаниях.
Неудивительно, ведь разве это правда? Разве нужно решать вопрос самому, если это и другие могут сделать?
Верный вопрос" :
Кто не читал - не поленитесь, прочитайте - рассказ небольшой : )
Чем-то это напоминает ситуацию из рассказа Шекли "Один на планете - не большой и не малой, а как раз подходящего размера - ждал ответчик. Он не может помочь тем, кто приходит к нему, ибо даже Ответчик не всесилен.
Вселенная? Жизнь? Смерть? Багрянец? Восемнадцать?
Частные Истины, полуистины, крохи великого вопроса.
И бормочет Ответчик вопросы сам себе, верные вопросы, которые никто не может понять.
И как их понять?
Чтобы правильно задать вопрос, нужно знать большую часть ответа.
Кто не читал - не поленитесь, прочитайте - рассказ небольшой : )
Он там вообще не отвечал на неправильно поставленные вопросы. А Гугл отвечает. Можно изучить, что он ответил и видоизменить вопрос. Хотя, конечно, это иногда не помогает - Гугл не знает всего.
Оставить комментарий
jupol
Что добавить в squid.conf, чтобы он направлял весь трафффик на другой прокси?Это с помощью peer_cashe делается?