Re: [squid-users] delay access to cached objects
Thanks Mehdi, I shall try the path you have shown. Regards On 25/06/06, Mehdi Sarmadi <[EMAIL PROTECTED]> wrote: > I guess, it could be possible running two squids one cache-only and > the other delay_pool-only(with caching disabled) chained > > On 6/25/06, Santosh Rani <[EMAIL PROTECTED]> wrote: > > Hello, > > Is it possible? I want that the objects from the cache should not be > > served instantly. > > Your help is needed please. > > Regards > > > > > -- > Mehdi Sarmadi >
[squid-users] ACL not playing nicely..
Hi All, I'm trying to apply the following ACL to block skype traffic... acl numeric_IPs urlpath_regex ^[0-9]+\.[0-9]+\.[0-9]+\.[0-9]+ acl Connect method CONNECT http_access deny Connect numeric_IPs all It should work - simple enough ACL - but it does not and i'm pretty stumped. I've just tried "http_access deny numeric_IPs" and still it does not work... Thanks in advance. Karl -- Signature withheld due to peer pressure.
RE: [squid-users] NTLM Auth with Parent Cache
Thanks, it's working great now. -Original Message- From: Henrik Nordstrom [mailto:[EMAIL PROTECTED] Sent: Friday, June 23, 2006 3:13 AM To: David Gullett Cc: squid-users@squid-cache.org Subject: Re: [squid-users] NTLM Auth with Parent Cache tor 2006-06-22 klockan 21:52 -0500 skrev David Gullett: > I can turn on NTLM auth at any of the branch offices and it will work until > I turn on NTLM auth at the main office. Then the main office will work with > NTLM but the users at the branch offices are being prompted for a username > and password which will never authenticate. I also get errors like this in > the squid logs at the branches: "Unexpected change of authentication scheme > from 'ntlm' to 'Basic" You need to allow the second-level caches access to the parent without requiring authentication. This is done in http_access. Regards Henrik
[squid-users] Squid 2.6-RC2 released for testing
The Squid Web Proxy developers are pleased to announce the availability of the Squid-2.6 Release Candidate 2, fixing a few issues found in the first release candidate plus a bit of cleanup. Squid-2.6 based on the Squid-2.5 codebase, but has many many new enhancements and new features which have been developed by numerous developers over the last three years and have now been rolled into this formal release. Squid-2.6 is planned to be the last major Squid-2 release. Further development will go into the much awaited Squid-3 train of software which is under active development. Please note that Squid-2.6-RC2 is PRERELEASE software and not intended to be run in a production environment. While we believe this software is likely to be free of major defects, it requires considerably more testing before we can consider it to be stable. This new release can be downloaded from our HTTP or FTP servers http://www.squid-cache.org/Versions/v2/2.6/ ftp://ftp.squid-cache.org/pub/squid-2/DEVEL/ or the mirrors. For a list of mirror sites see http://www.squid-cache.org/Mirrors/http-mirrors.html http://www.squid-cache.org/Mirrors/ftp-mirrors.html Users who download this software must understand that they will not receive support for this PRERELEASE software once Squid-2.6.STABLE is released. Thus users who are not prepared to upgrade to the final version when it is released or do not have time to file bug reports on any bugs or crashes you encounter with this Release Candidate, should continue to run the Squid-2.5.STABLE branch. We openly welcome and encourage bug reports, which can be entered into the Squid Bugzilla at http://www.squid-cache.org/bugs/index.cgi>. The most important new additions in this Squid-2.6 release are: * Major rewrite of the code and simplication of the configuration which handles reverse-proxy or transparently intercepting mode of operation * WCCPv2 support * Support for epoll under Linux and kqueue under FreeBSD for heavily loaded servers * ETag and Vary HTTP header support * Numerous authentication improvements * Enhanced operation and integration into Microsoft Windows For a more information on the individual changes see the Squid-2.6 changes page http://www.squid-cache.org/Versions/v2/2.6/changesets/>, For more information on changes to squid.conf and other notes related to upgrading from Squid-2.5 see the RELEASENOTES http://www.squid-cache.org/Versions/v2/2.6/RELEASENOTES.html> This Squid-2.6 software was brought to you by Henrik Nordstrom and the rest of the Squid Web Proxy Development team, and in part based on countless third-party contributions made available over the years. Many thanks to all contributors who have either hired Squid developers for developing new features of submitted new features themselves. Note: If there is interest in becoming a sponsor for the ongoing Squid maintenance or development efforts please contact [EMAIL PROTECTED] Regards The Squid Web Proxy developers signature.asc Description: Detta är en digitalt signerad meddelandedel
Re: [squid-users] squid performance issues
sön 2006-06-25 klockan 18:47 +0300 skrev E.S. Rosenberg: > 2. a 279 line whitelist, type: regex -i > > 3. a 5755 line blacklist, type: regex -i Are you sure these two should be regex:es? regex lists should only be used as a very last resort if none of the structured acls fits.. > 1. The blacklists is mainly a long list of hosts/websites (and various > IPs), removing them from the DNS (or changing their address to an > internal redirect) would make them unreachable (effectivly blocked) > while also reducing the size of the blacklist by roughly 80%. dstdomain and dst tupe acls... > 2. based on descriptions of how acls in squid worked (it goes through it > and first hit 'falls out') I thought that maybe adding high-traffic > sites to the top of the whitelist would reduce general load. cutting down on the number of regexes and better use of the available acl types is likely to buy you a lot more, Regards Henrik signature.asc Description: Detta är en digitalt signerad meddelandedel
[squid-users] squid performance issues
Hi, We are having some performance issues with squid: The setup is like this: 1. a bunch of short acls with special exceptions (hosts and stuff) 2. a 279 line whitelist, type: regex -i 3. a 5755 line blacklist, type: regex -i 4. various small acls (authentication is somewhere here). I had 2 ideas for reducing load on the proxy: 1. The blacklists is mainly a long list of hosts/websites (and various IPs), removing them from the DNS (or changing their address to an internal redirect) would make them unreachable (effectivly blocked) while also reducing the size of the blacklist by roughly 80%. 2. based on descriptions of how acls in squid worked (it goes through it and first hit 'falls out') I thought that maybe adding high-traffic sites to the top of the whitelist would reduce general load. I hope these ideas make some (if limited amount of) sense, and would like to hear what you think of them. Thanks for your time. Regards, E.S. Rosenberg
Re: [squid-users] HTTPS and delay_pools
sön 2006-06-25 klockan 10:50 +0330 skrev Mehdi Sarmadi: > I hoped that URLs with Multimedia, Binary, ... extentions could fall > in delay_pool number 1, but all of them fall into delay_pool number 1. HTTPS requests is encrypted. The proxy have no idea of what URL is requested.. The little information available to the proxy is: * Client station IP * Method CONNECT * Requested host (i.e. www.example.com) * Requested port (i.e. 443) * DNS resolved IP of the requested host name (i.e. 192.0.2.42) f) DNS resolved name of the client station IP g) Time of day h) Proxy-Authentication > I guess the problem is I could not match urlpath_regex in an HTTPS > session, isn't it? Correct. There is no urlpath at all in CONNECT requests. Regards Henrik signature.asc Description: Detta är en digitalt signerad meddelandedel
Re: [squid-users] Squid, HTTP/1.0, and HTTP/1.1
lör 2006-06-24 klockan 20:51 -0700 skrev Merton Campbell Crockett: > In this instance, Squid received an HTTP/1.1 response from the IIS > 6.x server with a status of 401. Included in the HTTP response > header were the following fields. > > WWW-Authenticate: Negotiate > WWW-Authenticate: NTLM > > Squid returned an HTTP/1.0 response to the IE client. The above were > not included in the HTTP response header. As the WWW-Authentic is > required in both HTTP/1.0 and HTTP/1.1 specifications, Squid is > returning an invalid response header. It I understand your response > correctly, this is intentional. Correct, as returning the above two HTTP-violating headers makes more damage than good. (well, the headers as such is not HTTP violations, but their implementations of the NTLM, Negotiate and Kerberos schemes ontop of HTTP is) This filter was added to prevent major security issues from relaying these non-HTTP authentication methods via a RFC compliant HTTP proxy such as Squid. At about the same time Microsoft added their own filters to MSIE ignoring these headers when using a proxy for the exact same reasons, and published a document on how proxies can announce to MSIE that the proxy does support the deviations from the HTTP protocol required to support these authentication schemes. This extension to HTTP is supported in Squid-2.6 and later. Regards Henrik signature.asc Description: Detta är en digitalt signerad meddelandedel
Re: [squid-users] delay access to cached objects
I guess, it could be possible running two squids one cache-only and the other delay_pool-only(with caching disabled) chained On 6/25/06, Santosh Rani <[EMAIL PROTECTED]> wrote: Hello, Is it possible? I want that the objects from the cache should not be served instantly. Your help is needed please. Regards -- Mehdi Sarmadi
[squid-users] delay access to cached objects
Hello, Is it possible? I want that the objects from the cache should not be served instantly. Your help is needed please. Regards
Re: [squid-users] HTTPS and delay_pools
The delay_pool and ACL directives that I've used are: === # Multimedia file extension, -i : case insensitive acl mm_ext urlpath_regex -i \.mp3$ \.avi$ \.mov$ \.mpeg$ \.mpg$ \.divx$ \.mp4$ \.xvid$ \.axf$ \.3gp$ \.img2$ \.wma$ \.wmv$ acl compressed urlpath_regex -i \.rar$ \.zip$ acl executablebinary urlpath_regex \.exe$ \.msi$ \.bin$ \.iso$ #delay_pools delay_pools 3 delay_class 1 2 delay_class 2 2 delay_class 3 2 delay_parameters 3 25000/25000 25000/25000 delay_parameters 2 26/26 26/26 delay_parameters 1 35000/35000 35000/35000 delay_initial_bucket_level 50 delay_access 3 allow executablebinary delay_access 3 allow compressed delay_access 3 deny all delay_access 2 allow needbw delay_access 2 allow !mm_ext !executablebinary !compressed delay_access 2 deny all delay_access 1 allow mm_ext delay_access 1 deny all === I hoped that URLs with Multimedia, Binary, ... extentions could fall in delay_pool number 1, but all of them fall into delay_pool number 1. I guess the problem is I could not match urlpath_regex in an HTTPS session, isn't it? If yes, Any clue? On 6/25/06, Henrik Nordstrom <[EMAIL PROTECTED]> wrote: sön 2006-06-25 klockan 01:41 +0330 skrev Mehdi Sarmadi: > Could https requests/replies fall in delay_pools? Yes. > If yes, How to? Should by default, unless you use some incompatible ACLs in your delay_access... As for all the other protocols the delay pools only applies on internet->client traffic. Not client->internet traffic. Regards Henrik -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.3 (GNU/Linux) iD8DBQBEncOzB5pTNio2V7IRAhLvAJ4kTjglxuxCFER/fqm32cFgyz7k4wCfUO/Y 3v285H3EE/v9aT/YWMKf4Yg= =3YVr -END PGP SIGNATURE- -- Mehdi Sarmadi
