Re: [squid-users] Large ACLs and TCP_OUTGOING_ADDRESS
> Hi, > > I run squid in an ISP scenario. We have got two identically configured > squid caches being load balanced among 4,000 users over a 50 Mbps link. > The > system runs quite well, although not without the occassional hiccups. > But, > there is a complain from users about not being able to access some > websites > because of same external IP. For this, we configured the squid.conf to > have > ACLs for different user blocks of /24 and have them mapped through > different > external IPs on each of these boxes. > > However, not all /24 blocks have the same number of users, and I also have > lots of real IPs still lying unused. I thought about creating different > ACLs for every 5 or 8 users, and then map them to different external IPs. > But, having them distributed in 8 IPs in each group would mean at least > 500 > separate ACLs and their corresponding TCP_OUTGOING_ADDRESS directives. > > My question is, will this affect the performance of squid? Can squid > handle > this? Depends on the ACL type. Squid should be able to handle many easily. of the ACl you need; src is the fastest, next best is dstdomain, then dst. So for a marginal boost when combining on one line, put then in that order. Just look for shortcuts as you go. > > My servers are each running on Core 2 Duo 2.33 GHz, 8 GB of RAM, 5 HDDs > (1x80GB IDE for OS, 4x160GB SATA for cache), total 256GB Cache Store (64GB > on each HDD). One of the server's stats are (taken at a very low user > count > time): Thank you. We are trying to collect rough capacity info for Squid whenever the opportunity comes up. Are you able to provide such stats around peak load for our wiki? The info we collect can be seen at http://wiki.squid-cache.org/KnowledgeBase/Benchmarks Amos
[squid-users] Large ACLs and TCP_OUTGOING_ADDRESS
Hi, I run squid in an ISP scenario. We have got two identically configured squid caches being load balanced among 4,000 users over a 50 Mbps link. The system runs quite well, although not without the occassional hiccups. But, there is a complain from users about not being able to access some websites because of same external IP. For this, we configured the squid.conf to have ACLs for different user blocks of /24 and have them mapped through different external IPs on each of these boxes. However, not all /24 blocks have the same number of users, and I also have lots of real IPs still lying unused. I thought about creating different ACLs for every 5 or 8 users, and then map them to different external IPs. But, having them distributed in 8 IPs in each group would mean at least 500 separate ACLs and their corresponding TCP_OUTGOING_ADDRESS directives. My question is, will this affect the performance of squid? Can squid handle this? My servers are each running on Core 2 Duo 2.33 GHz, 8 GB of RAM, 5 HDDs (1x80GB IDE for OS, 4x160GB SATA for cache), total 256GB Cache Store (64GB on each HDD). One of the server's stats are (taken at a very low user count time): Squid Object Cache: Version 2.7.STABLE4 Connection information for squid: Number of clients accessing cache: 2281 Number of HTTP requests received: 46553879 Number of ICP messages received: 10546598 Number of ICP messages sent: 10548558 Number of queued ICP replies: 0 Request failure ratio: 0.00 Average HTTP requests per minute since start: 7237.3 Average ICP messages per minute since start: 3279.5 Select loop called: 617194936 times, 0.625 ms avg Cache information for squid: Request Hit Ratios: 5min: 30.7%, 60min: 30.2% Byte Hit Ratios: 5min: 7.1%, 60min: 5.4% Request Memory Hit Ratios: 5min: 20.6%, 60min: 20.5% Request Disk Hit Ratios: 5min: 32.3%, 60min: 32.7% Storage Swap size: 241785428 KB Storage Mem size: 4194120 KB Mean Object Size: 35.02 KB Requests given to unlinkd: 0 Median Service Times (seconds) 5 min60 min: HTTP Requests (All): 0.72387 0.33943 Cache Misses: 0.76407 0.55240 Cache Hits:0.15048 0.03241 Near Hits: 0.89858 0.61549 Not-Modified Replies: 0.04277 0.00286 DNS Lookups: 0.04433 0.02447 ICP Queries: 0.03246 0.00037 Resource usage for squid: UP Time: 385950.900 seconds CPU Time: 51642.987 seconds CPU Usage: 13.38% CPU Usage, 5 minute avg: 35.09% CPU Usage, 60 minute avg: 40.76% Process Data Segment Size via sbrk(): 654836 KB Maximum Resident Size: 0 KB Page faults with physical i/o: 4 Memory usage for squid via mallinfo(): Total space in arena: -1798084 KB Ordinary blocks: 2081758 KB 2399729 blks Small blocks: 0 KB 0 blks Holding blocks: 35360 KB 8 blks Free Small blocks: 0 KB Free Ordinary blocks: 314461 KB Total in use: -2077186 KB 118% Total free:314461 KB -17% Total size:-1762724 KB Memory accounted for: Total accounted: 5839838 KB memPoolAlloc calls: 2143236778 memPoolFree calls: 2113174187 File descriptor usage for squid: Maximum number of file descriptors: 65536 Largest file desc currently in use: 8734 Number of file desc currently in use: 1413 Files queued for open: 0 Available number of file descriptors: 64123 Reserved number of file descriptors: 100 Store Disk files open: 62 IO loop method: epoll Internal Data Structures: 6913382 StoreEntries 324677 StoreEntries with MemObjects 324228 Hot Object Cache Items 6905066 on-disk objects Can anybody advise? Regards NYAMUL HASSAN
RE: [squid-users] Re: squid_ldap_auth and passwords in clear text
> IMHO these days Ethernet eavesdropping really isn't much of > an issue (despite conventional wisdom:-). Much more dangerous > are spyware/trojan keyloggers; server penetration is annother danger. > > Eavesdropping on all network traffic from any connection used > to be a big problem when network hubs repeated all traffic > everywhere. Although Ethernet has changed hugely, the old > paranoia remains. Any modern device is > a "switch" (not a "hub") and only directs traffic to the one > port it's destined for, so nobody else can eavesdrop. Wrong. (Unless you run Cisco with DHCP snooping with Dynamic ARP Inspection, or similar) This will allow you to sniff on switches; http://ettercap.sourceforge.net/ http://www.monkey.org/~dugsong/dsniff/
[squid-users] Re: squid_ldap_auth and passwords in clear text
> ... but when watching the protocol analyzer I see ... IMHO these days Ethernet eavesdropping really isn't much of an issue (despite conventional wisdom:-). Much more dangerous are spyware/trojan keyloggers; server penetration is annother danger. Eavesdropping on all network traffic from any connection used to be a big problem when network hubs repeated all traffic everywhere. Although Ethernet has changed hugely, the old paranoia remains. Any modern device is a "switch" (not a "hub") and only directs traffic to the one port it's destined for, so nobody else can eavesdrop. Of course even with "switches" you should take some reasonable precautions: 1) Ensure whatever you do to get your sniffer to work is inaccessible to users. 2) Keep all network infrastructure physically inaccessible, perhaps by locking the wiring closets. 3) Restrict (password protect and more) and monitor "remote" access to all network infrastructure devices. 4) Keep all servers (Squid, etc.) physically inaccessible. 5) Severely restrict (or disallow altogether) "remote" access to all servers (ex: only SSH and never as root and only with a public/private key). 6) Avoid using those cheap "mini-hubs" (often 5-port) unless you're sure your model really function as switches despite their name. thanks! -Chuck Kollars
RE: [squid-users] NTLM auth popup boxes && Solaris 8 tuning for upgrade into 2.7.4
> hello all, > > I currently get some sun v210 boxes running solaris 8 and >> squid-2.6.12 > and samba 3.0.20b I will upgrade these proxies into 2.7.4/3.0.32 next > monday but before doing this I would like to ask you your advices and/or > experiences with tuning these kind of boxes. > > the service is running well today except we regularly get authentication > popup boxes. This is really exasperating our Users. I already spent >> lot > of times on the net in the hope finding a clear explanation about it but > i am still searching. I already configured starting 128 ntlm_auth > processes on each of my servers. This gives better results but >> problem > still remains. I also made some patching in my new package I will deploy > next week by overwrting some samba values .. below my little patch .. > >> >> first of all, man thanks to enter this discussion in order to help me >> solve my problems .. >> >>> Before digging deep into OS settings check your squid.conf auth, acl >> and >>> http_access settings. >> >> okay let's go concerning auth part of the squid.conf, I would like to >> say, nothing special .. below the ntlm config part >> >> auth_param ntlm program /usr/local/bin/ntlm_auth >> --helper-protocol=squid-2.5-ntlmssp >> auth_param ntlm children 128 >> auth_param ntlm keep_alive on >> acl ntlmauth proxy_auth REQUIRED >> ... >> http_access allow ntlmauth all >> http_reply_access allow all >> http_access deny all >> deny_info TCP_RESET all >> > >Hmm, what those lines do is: > - test the request for auth details (allow ntlmauth), > - if correct details found, allow (allow ntlmauth all). > - if none are found, or bad details ignore (allow ntlmauth all) > - but send a RESET on the TCP link (deny all + TCP_RESET) something I tried last week to see if it could solve my problem. > >The clients will never get any correction when auth details are invalid. >They will just get a completely new session, the browser will try to >resend the same broken details until it gives up and re-asks the user. > > >The 'all' silencing hack is intended for situations where auth may be >the preferred methods of access, but an alternative exists and can be >taken easily when it fails. It prevents the browser being notified when >credentials are wrong. > >Does it work if you make that line just: http_access allow ntlmauth indeed seems also working, if no valid credential 'cache access denied' otherwise goes to internet. does it change the internal squid behaviour by removing all ?? > >>> Check the TTL settings on your auth config. If it's not long enough >> squid >>> will re-auth between request and reply. >> >> not really sure to understand what setting you are speaking about ?? >> > >auth_param ntlm ttl do you advice using it because I do not find any reference on it on squid configuration guide website. > >Amos >-- >Please be using > Current Stable Squid 2.7.STABLE5 or 3.0.STABLE10 > Current Beta Squid 3.1.0.2 - ATTENTION: The information in this electronic mail message is private and confidential, and only intended for the addressee. Should you receive this message by mistake, you are hereby notified that any disclosure, reproduction, distribution or use of this message is strictly prohibited. Please inform the sender by reply transmission and delete the message without copying or opening it. Messages and attachments are scanned for all viruses known. If this message contains password-protected attachments, the files have NOT been scanned for viruses by the ING mail domain. Always scan attachments before opening them. -
[squid-users] storeSwapMetaUnpack: insane length
I'm seeing this error in cache.log when restarting squid: storeSwapMetaUnpack: insane length (-663045478)! My understanding is that it's complaining about a URL length and the weird value seems to indicate the store has been corrupted? Is there a way to fix this without clearing the entire cache?
