Thanks Amos!
I updated "auth_param basic credentialsttl" according to your advice and it is working great.
I am still having issues with the "tcp_outgoing_address 192.168.8.12 acl_for_user3002" part, you mentioned:
> For ACLs with values that are expected to change often it is best to use> an external_acl_type helper that manages the updates or fetches from
> somewhere the updates are handled without a reload.
My script updates the authenticator successfully, but when I update "acl acl_for_user3002 proxy_auth user2" to the new username I have to reconfigure to take effect.
I read online for hours but to my best understanding external_acl_type are for auth and access control, but they don't work for my needs I believe.
Is there any way to use external_acl_type in a way I don't understand to solve this problem? Do I have to reconfigure every time I make changes to an ACL in squid.conf?
Thanks again for your help.
On Sat, Oct 31, 2020 at 5:48 PM Amos Jeffries <squid3@xxxxxxxxxxxxx> wrote:
On 31/10/20 1:34 pm, roee klinger wrote:
>
> Hey,
> I have Squid configured to send users to different outgoing interface like so:
>
> ..
> auth_param basic program /usr/lib/squid/basic_ncsa_auth /etc/squid/htpassword
> acl acl_for_user3002 proxy_auth user2
> tcp_outgoing_address 192.168.8.12 acl_for_user3002
> http_port 3002 name=3002
No need to name a *_port like this. The default name is the first
parameter string ("3002" on this line).
> http_access allow authenticated
> ..
>
> When I wanted to change the username:password for user2, I run a bash script to change it in squid.conf and also in htpassword and then I run "squid -k reconfigure", if I don't reconfigure the old user still has access to the proxy and the new one doesn't for about 30 minutes.
>
No need to restart for that change. The helper you have there will
automatically detect changes to the htpassword file and reload it.
It is a little odd that the new user was not able to authenticate. Check
that your test did not lookup and cache a non-existence result for them
prior to being added.
The delay is due to the credentials being valid for a period of time. To
reduce workload on the auth system Squid caches credential details for a
while.
Set "auth_param basic credentialsttl " to shorter values to reduce the
delay (default is 2hrs).
> I am expecting to have 100s of users soon that will change credentials often, and also I would like to blacklist websites often and on the fly, so I was searching for a better way to manage this without reconfiguring every time, since sometimes a reconfigure can take up to 10-15 seconds.
>
This helper does not need a reconfigure at all as far as I can tell from
the code.
All the reconfigure was doing for you previously was triggering an early
prune of the records in the credentials cache. Probably why you saw
about 30min delay instead of about 2hrs.
> I am new to Squid and wasn't able to find any info on this, am I doing this currently or there is a better way to change users/ACLs on the fly without reloading Squid?
>
Config changes in squid.conf itself needs a reconfigure or sometimes a
restart.
For auth and ACLs whose values that come into Squid from a helper it
depends on the helper itself. Most can auto-detect changes to their
background databases and not need anything from Squid to update the
outputs. All helpers do have some form of caching of their results by
Squid, so there are settings in squid.conf to tune that to your needs -
as you can see from the auth issue above.
For ACLs with values that are expected to change often it is best to use
an external_acl_type helper that manages the updates or fetches from
somewhere the updates are handled without a reload.
Amos
_______________________________________________
squid-users mailing list
squid-users@xxxxxxxxxxxxxxxxxxxxx
http://lists.squid-cache.org/listinfo/squid-users
_______________________________________________ squid-users mailing list squid-users@xxxxxxxxxxxxxxxxxxxxx http://lists.squid-cache.org/listinfo/squid-users
