[squid-users] authenticate users by Active Directory
1- Can I authenticate my users by Active Directory ? I have 3 Domain Controller servers where my domain is 'intern.it' (MS DNS) I have another domain, on the external side (extern.it) , which I use to publish web services and SMTP traffic (Linux srv, Bind9 package) Clients use MS internal dns, while Squid uses extern dns. Squid (2.7 Stable3) and Bind services are on the same server. 2- In order to integrating Squid authentication to Active Directory, can keep these 2 domains as now (divided and independent) ? I read that, for creating this system, I have to insert my squid into domain, by SAMBA package, but my purpose is keeping same behaviour and environment. Riccardo
[squid-users] is it possible to log if a client cancels a download ?
Hello, when a user canceled a download, I can't see it in the access.log and cache.log. Is it possible to log the reason, why the download is cancled. In access.log file I see only the 200 HTTP status code. -- Best regards Dieter -- I do not get viruses because I do not use MS software. If you use Outlook then please do not put my email address in your address-book so that WHEN you get a virus it won't use my address in the From field. signature.asc Description: Digital signature
Re: [squid-users] is it possible to log if a client cancels a download ?
On 14/10/10 22:02, Dieter Bloms wrote: Hello, when a user canceled a download, I can't see it in the access.log and cache.log. Is it possible to log the reason, why the download is cancled. The ONLY way to cancel a download in TCP is to close the connection. There is no reason for closure. In access.log file I see only the 200 HTTP status code. The very latest releases (3.2 beta series) log this as TCP_*_ABORTED and TCP_*_TIMEOUT. ABORTED being a client-closed connection. The cancel you describe above. Amos -- Please be using Current Stable Squid 2.7.STABLE9 or 3.1.8 Beta testers wanted for 3.2.0.2
[squid-users] Leaking ICAP connections
I am using Squid 3.1.0.14, configured to make REQMOD and RESPMOD requests to a local ICAP server. Everything seems to work fine, except the number of connections between Squid and the ICAP server sometimes keeps increasing over the course of days or weeks. I haven't been able to figure out what is triggering the problem, but it appears that in certain circumstances, Squid just stops using one of the ICAP connections - from what I can tell, the ICAP server has finished dealing with a request and is waiting for the next one, but Squid never sends a new request. Squid continues to operate ok, bringing up more ICAP connections to accommodate more client requests whilst the lost connection stays dormant. The ICAP server is configured to allow a maximum of 100 concurrent connections and eventually, the number of lost connections becomes so great that this limit is reached and the ICAP server starts rejecting the new connections that Squid is bringing up. At this point the users start getting Squid's ICAP error page. Since I'm unfamiliar with the internal structure of Squid, I'm not really sure where to begin with debugging Squid itself. I think I've done as much debugging as is possible from the ICAP server side (this seems to indicate that the ICAP session itself has been fine - the last ICAP request from Squid looks fine and has terminated and the last ICAP response from the ICAP server looks fine and the server is sat waiting for a new request that never comes). This problem isn't something that can be reliably worked around on the ICAP server end - the ICAP server has no way of knowing if a connection from Squid has been lost (i.e. still open but will never again be used) or if it is simply idle. Because of this, having the ICAP server time out idle connections would introduce a race condition - if the connection is just idle, rather than lost, the ICAP server might time it out and close it just as Squid starts sending a new request; in this case the request would fail and the user would get an error page. Any suggestions on how to debug the problem would be greatfully received. Thanks. -- - Steve Hill Technical Director Opendium Limited http://www.opendium.com
Re: [squid-users] Leaking ICAP connections
On 15/10/10 02:36, Steve Hill wrote: I am using Squid 3.1.0.14, configured to make REQMOD and RESPMOD requests to a local ICAP server. Everything seems to work fine, except the number of connections between Squid and the ICAP server sometimes keeps increasing over the course of days or weeks. I haven't been able to figure out what is triggering the problem, but it appears that in certain circumstances, Squid just stops using one of the ICAP connections - from what I can tell, the ICAP server has finished dealing with a request and is waiting for the next one, but Squid never sends a new request. Squid continues to operate ok, bringing up more ICAP connections to accommodate more client requests whilst the lost connection stays dormant. The ICAP server is configured to allow a maximum of 100 concurrent connections and eventually, the number of lost connections becomes so great that this limit is reached and the ICAP server starts rejecting the new connections that Squid is bringing up. At this point the users start getting Squid's ICAP error page. Since I'm unfamiliar with the internal structure of Squid, I'm not really sure where to begin with debugging Squid itself. I think I've done as much debugging as is possible from the ICAP server side (this seems to indicate that the ICAP session itself has been fine - the last ICAP request from Squid looks fine and has terminated and the last ICAP response from the ICAP server looks fine and the server is sat waiting for a new request that never comes). This problem isn't something that can be reliably worked around on the ICAP server end - the ICAP server has no way of knowing if a connection from Squid has been lost (i.e. still open but will never again be used) or if it is simply idle. Because of this, having the ICAP server time out idle connections would introduce a race condition - if the connection is just idle, rather than lost, the ICAP server might time it out and close it just as Squid starts sending a new request; in this case the request would fail and the user would get an error page. Any suggestions on how to debug the problem would be greatfully received. First step is upgrading to 3.1.8 to see if its one of the many found and solved bugs. If its still remains there check bugzilla for any references. Amos -- Please be using Current Stable Squid 2.7.STABLE9 or 3.1.8 Beta testers wanted for 3.2.0.2
