On 12/05/2016 8:42 p.m., C. L. Martinez wrote: > On Wed 11.May'16 at 21:14:08 +0600, Yuri Voinov wrote: >> >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA256 >> >> >> 11.05.16 21:04, L.P.H. van Belle пишет: >>> >>> Hai, >>> >>> >>> >>> I reviewd your config, thing whats different in c-icap.conf compared >> to me. >>> >> Obviously, the mindless copying and pasting the config - very bad >> practice, is not it? >>> >>> RemoteProxyUsers off ( for you ) on for me. >>> >> # TAG: RemoteProxyUsers >> # Format: RemoteProxyUsers onoff >> # Description: >> # Set it to on if you want to use username provided by the proxy server. >> # This is the recomended way to use users in c-icap. >> # If the RemoteProxyUsers is off and c-icap configured to use users or >> # groups the internal authentication mechanism will be used. >> # Default: >> # RemoteProxyUsers off >> RemoteProxyUsers off >> >> This is depending proxy configuration. And irrelevant current case. >>> >>> >>> >>> Whats the content of /etc/c-icap/squidclamav.conf ? >>> >>> The important part for me of the file : >>> >>> #clamd_local /var/run/clamd.socket ! change/check this >>> >> This is OS-dependent, as obvious. >>> >>> clamd_ip 127.0.0.1 >>> >>> clamd_port 3310 >>> >>> >>> >>> If you use socket make sure your rights are correct and icap is added >> to the clamav group. >>> >> Wrong. Squid group, not clamav. >>> >>> >>> >>> >>> >>> And my c-icap part of the squid.conf >>> >>> ## Tested with Squid 3.4.8 and 3.5.x + squidclamav 6.14 and 6.15 >>> >>> icap_enable on >>> >>> icap_send_client_ip on >>> >>> icap_send_client_username on >>> >>> icap_client_username_header X-Authenticated-User >>> >>> icap_persistent_connections on >>> >>> icap_preview_enable on >>> >>> icap_preview_size 1024 >>> >>> icap_service service_req reqmod_precache bypass=1 >> icap://127.0.0.1:1344/squidclamav >>> >>> adaptation_access service_req allow all >>> >>> icap_service service_resp respmod_precache bypass=1 >> icap://127.0.0.1:1344/squidclamav >>> >>> adaptation_access service_resp allow all >>> >>> >>> >>> I think you changed to much in the example. >>> >>> >>> >>> Im reffering to these in the squid.conf >>> >>>> adaptation_access service_avi_resp allow all >>> >>> service_avi_resp? >>> >>> >>> >> Complete squid.conf fragment: >> >> icap_service service_avi_req reqmod_precache >> icap://localhost:1344/squidclamav bypass=off >> adaptation_access service_avi_req allow all >> icap_service service_avi_resp respmod_precache >> icap://localhost:1344/squidclamav bypass=on >> adaptation_access service_avi_resp allow all >> >> Please, PLEASE, do not make recommendation when you not understand what >> does config lines means! >> > > Ok, problem is solved. Seems there is some problem between squid and my unbound DNS server. Changing the following lines: > > icap_service service_avi_req reqmod_precache icap://localhost:1344/squidclamav bypass=off > icap_service service_avi_resp respmod_precache icap://localhost:1344/squidclamav bypass=on > > to: > > icap_service service_avi_req reqmod_precache icap://127.0.0.1:1344/squidclamav bypass=off > icap_service service_avi_resp respmod_precache icap://127.0.0.1:1344/squidclamav bypass=on > > all works as expected. As you can see I have changed "localhost" for "127.0.0.1" ... localhost entry exists inside my /etc/hosts file, and OpenBSD resolves correctly, but under unbound's config I have enabled "do-not-query-localhost: no" because unbound is configured to work with dnscrypt-proxy service... > > I am not sure about this, but it is the only answer that explains this problem ... or it is a bug (but I don't think so). > > What do you think?? > I think that Squid told you it was sending an OPTIONS request to ICAP service, which failed. So it marked the service down. The service was not allowed to be bypassed (bypass=off), so cannot cope with being down. It is possible "localhost" had to be resolved to do that OPTIONS request. However, if as you say it already has an entry in your /etc/hosts file then Squid should have loaded that entry as a permanent record and never be looking it up in DNS. Amos _______________________________________________ squid-users mailing list squid-users@xxxxxxxxxxxxxxxxxxxxx http://lists.squid-cache.org/listinfo/squid-users
