Tks for the answers. Considerations: 1- "Please note that you are allowing authenticated clients to send traffic to unsafe ports. For example, they can CONNECT to non-SSL ports. You may want to reorder the above rules if that is not what you want." ANSWER: Tks for the advice, I already had it changed. 2- "However, you should also ask yourself another question: "Why am I using multiple http_ports if all I care about is who uses which tcp_outgoing_address?". The listening ports have virtually nothing to do with tcp_outgoing_address..." ANSWER: Because I have to route each http_port to specific tcp_outgoing_address. I have several customers per VPS. Each one uses like 10 different ports to direct connections through different IPv6s. 3- "Use http_access to deny authenticated users connected to wrong ports." ANSWER: So, in this scenario, how can I prevent users in the same users list to access ports that not belong to them. How to deny it in http_access rules? Marcelo -----Mensagem original----- De: squid-users [mailto:squid-users-bounces@xxxxxxxxxxxxxxxxxxxxx] Em nome de squid-users-request@xxxxxxxxxxxxxxxxxxxxx Enviada em: terça-feira, 16 de novembro de 2021 15:23 Para: squid-users@xxxxxxxxxxxxxxxxxxxxx Assunto: squid-users Digest, Vol 87, Issue 19 Send squid-users mailing list submissions to squid-users@xxxxxxxxxxxxxxxxxxxxx To subscribe or unsubscribe via the World Wide Web, visit http://lists.squid-cache.org/listinfo/squid-users or, via email, send a message with subject or body 'help' to squid-users-request@xxxxxxxxxxxxxxxxxxxxx You can reach the person managing the list at squid-users-owner@xxxxxxxxxxxxxxxxxxxxx When replying, please edit your Subject line so it is more specific than "Re: Contents of squid-users digest..." Today's Topics: 1. Multi-clients VPS - Authentication been shared. (Graminsta) 2. Re: Too many ERROR: Collapsed forwarding queue overflow for kid2 at 1024 items (Lou?ansk? Luk??) 3. Re: Stable Squid Version for production on Linux (David Touzeau) 4. Re: Too many ERROR: Collapsed forwarding queue overflow for kid2 at 1024 items (Alex Rousskov) 5. Re: Multi-clients VPS - Authentication been shared. (Alex Rousskov) ---------------------------------------------------------------------- Message: 1 Date: Tue, 16 Nov 2021 13:53:52 -0300 From: "Graminsta" <marcelorodrigo@xxxxxxxxxxxxxxxx> To: <squid-users@xxxxxxxxxxxxxxxxxxxxx> Subject: Multi-clients VPS - Authentication been shared. Message-ID: <005e01d7db0a$8ab2ab80$a0180280$@graminsta.com.br> Content-Type: text/plain; charset="us-ascii" Hello friends, I'm using these user authentication lines in squid.conf based on user's authentication list: auth_param basic program /usr/lib/squid/basic_ncsa_auth /etc/squid/users auth_param basic children 5 auth_param basic realm Squid proxy-caching web server auth_param basic credentialsttl 2 hours auth_param basic casesensitive off http_access allow localhost acl clientes proxy_auth REQUIRED http_access allow clientes http_access deny !Safe_ports http_access deny CONNECT !SSL_ports http_access allow localhost manager http_access deny manager http_access deny all #List of outgoings (all IPs are fake) http_port 181.111.11.111:4000 name=3 acl ip3 myportname 3 tcp_outgoing_address 2804:1934:2E1::3D6 ip3 http_port 181.111.11.112:4001 name=4 acl ip4 myportname 4 tcp_outgoing_address 2804:1934:3a8::3D7 ip4 The problem is that everyone whom is in the users file are allow to use all tcp_outgoing_address. If a smarter client scans for open IPs and ports will be able to find these outgoings. How can I restrict each user to their own tcp_outgoing_address output? Tks. Marcelo -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.squid-cache.org/pipermail/squid-users/attachments/20211116/69f b0a22/attachment-0001.htm> ------------------------------ Message: 2 Date: Tue, 16 Nov 2021 18:00:56 +0100 From: Lou?ansk? Luk?? <Loucansky.Lukas@xxxxxx> To: "Alex Rousskov" <rousskov@xxxxxxxxxxxxxxxxxxxxxxx>, "Squid Users" <squid-users@xxxxxxxxxxxxxxxxxxxxx> Subject: Re: Too many ERROR: Collapsed forwarding queue overflow for kid2 at 1024 items Message-ID: <72DD5D5CF661B5459DC08A060BF26B53010897A8@xxxxxxxxxxxxxx.local> Content-Type: text/plain; charset="windows-1250" Ok - I will try to backport it from that patch into the v5 tree I've downloaded today. As we were using the mentioned build I came across these new assertions: 2021/11/16 10:29:46 kid1| assertion failed: StoreMap.cc:241: "anchorAt(anchorId).reading()" 2021/11/16 11:32:51 kid2| assertion failed: Transients.cc:221: "old == e" 2021/11/16 13:02:09 kid2| assertion failed: Transients.cc:221: "old == e" 2021/11/16 13:52:05 kid2| assertion failed: Transients.cc:221: "old == e" 2021/11/16 14:29:41 kid2| assertion failed: store.cc:1108: "store_status == STORE_PENDING" 2021/11/16 15:26:15 kid1| assertion failed: Transients.cc:221: "old == e" 2021/11/16 17:40:21 kid1| assertion failed: cbdata.cc:372: "c->locks > 0" 2021/11/16 17:40:44 kid1| assertion failed: cbdata.cc:115: "cookie == ((long)this ^ Cookie)" (no config changes) My 1w cache.log is about 300MB - without elevated debug options (debug options ALL,1) - so it?s not easy to find something relevant with "9" options enabled... LL -----Original Message----- From: Alex Rousskov [mailto:rousskov@xxxxxxxxxxxxxxxxxxxxxxx] Sent: Tuesday, November 16, 2021 3:42 PM To: Lou?ansk? Luk??; Squid Users Subject: Re: Too many ERROR: Collapsed forwarding queue overflow for kid2 at 1024 items On 11/16/21 4:38 AM, Lou?ansk? Luk?? wrote: > is it going to be patched only in the v6 version? I hope the existing fix applies to v5 cleanly, and I am ready to help with backporting if it does not. Beyond that, it is in the maintainer hands. I cannot predict whether or when the fix will be officially merged into v5 because I do not understand how those decisions are made. > Anyway - in the morning I run debug with 20,9 to see: > ... > 2021/11/16 09:02:06.496 kid2| assertion failed: Transients.cc:221: "old == e" Unfortunately, I cannot see the cause of the assertion in this short/partial trace -- the problematic actions happened before the trace or were not logged during the trace. Patching your Squid with commit 5210df4 is the best next step IMO. If that patch does not help, then there are probably other bugs that we need to fix in v5 (at least). HTH, Alex. > -----Original Message----- > From: Alex Rousskov [mailto:rousskov@xxxxxxxxxxxxxxxxxxxxxxx] > Sent: Monday, November 15, 2021 5:17 PM > To: Squid Users > Cc: Lou?ansk? Luk?? > Subject: Re: Too many ERROR: Collapsed forwarding queue > overflow for kid2 at 1024 items > > On 11/15/21 7:43 AM, Lou?ansk? Luk?? wrote: > >> 2021/11/14 10:13:30 kid2| assertion failed: Transients.cc:221: "old == e" >> 2021/11/15 08:37:36 kid2| assertion failed: Transients.cc:221: "old == e" >> 2021/11/15 11:54:14 kid1| assertion failed: Transients.cc:221: "old == e" >> 2021/11/15 12:16:27 kid1| assertion failed: Transients.cc:221: "old == e" > > I recommend ignoring queue overflows until the above assertions are fixed because worker deaths cause queue overflows. Your Squid is buggy, and those bugs essentially cause queue overflows. > > The assertion itself is known as Bug 5134: > https://bugs.squid-cache.org/show_bug.cgi?id=5134 > > That bug has a speculative fix (master/v6 commit 5210df4). Please try it if you can. > > > HTH, > > Alex. > > >> -----Original Message----- >> From: Alex Rousskov [mailto:rousskov@xxxxxxxxxxxxxxxxxxxxxxx] >> Sent: Friday, November 12, 2021 5:24 PM >> To: Lou?ansk? Luk??; squid-users@xxxxxxxxxxxxxxxxxxxxx >> Subject: Re: Too many ERROR: Collapsed forwarding queue >> overflow for kid2 at 1024 items >> >> On 11/11/21 10:19 AM, Lou?ansk? Luk?? wrote: >> >>> recently I'm facing too many ERROR: Collapsed forwarding queue >>> overflow for kid2 at 1024 items lines in my Squid 5.2 log files. >> >> We see those overflows when kids die. Do you see any FATAL messages, assertions, or similar deadly errors in cache.log? >> >> >>> Could someone elaborate how the queue is filled - what is clogging it? >> >> The sender/writer sends messages faster than the recipient/reader is >> reading them, eventually exceeding the queue capacity (i.e. 1024 >> messages). These messages are about Store entries that may need >> synchronization across workers. Each message is very sm > all. >> >> >>> I don't mind too much if I have to turn collapsed forwarding off >> >> Most likely, the problem is not tied to collapsed forwarding. These >> queues were used for collapsed forwarding when they were added, but >> they are used for regular traffic as well in modern SMP Squids. We >> need to change the queue names (and related code/m > essage text) to reflect the expanded nature of these queues. >> >> >> HTH, >> >> Alex. >> ------------------------------ Message: 3 Date: Tue, 16 Nov 2021 18:33:30 +0100 From: David Touzeau <david@xxxxxxxxxxxxxx> To: squid-users@xxxxxxxxxxxxxxxxxxxxx Subject: Re: Stable Squid Version for production on Linux Message-ID: <60b9c5c9-202c-ad3c-c90d-a78f45f6c89c@xxxxxxxxxxxxxx> Content-Type: text/plain; charset="utf-8"; Format="flowed" Hi, For us it is Squid v4.17 Le 16/11/2021 ? 17:40, Graminsta a ?crit?: > > Hey folks ?;) > > What is the most stable squid version for production on Ubuntu 18 or 20? > > Marcelo > > > _______________________________________________ > squid-users mailing list > squid-users@xxxxxxxxxxxxxxxxxxxxx > http://lists.squid-cache.org/listinfo/squid-users -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.squid-cache.org/pipermail/squid-users/attachments/20211116/5b3 1cc34/attachment-0001.htm> ------------------------------ Message: 4 Date: Tue, 16 Nov 2021 13:09:12 -0500 From: Alex Rousskov <rousskov@xxxxxxxxxxxxxxxxxxxxxxx> To: Lou?ansk? Luk?? <Loucansky.Lukas@xxxxxx>, Squid Users <squid-users@xxxxxxxxxxxxxxxxxxxxx> Subject: Re: Too many ERROR: Collapsed forwarding queue overflow for kid2 at 1024 items Message-ID: <369d5766-b6ab-f4cd-8cef-64b298d84638@xxxxxxxxxxxxxxxxxxxxxxx> Content-Type: text/plain; charset=windows-1250 On 11/16/21 12:00 PM, Lou?ansk? Luk?? wrote: > I will try to backport it from that patch into the v5 tree I've > downloaded today. As we were using the mentioned build I came across > these new assertions: > 2021/11/16 10:29:46 kid1| assertion failed: StoreMap.cc:241: "anchorAt(anchorId).reading()" > 2021/11/16 11:32:51 kid2| assertion failed: Transients.cc:221: "old == e" > 2021/11/16 14:29:41 kid2| assertion failed: store.cc:1108: "store_status == STORE_PENDING" I hope that at least some of the above assertions are fixed by master/v6 commit 5210df4. > 2021/11/16 17:40:21 kid1| assertion failed: cbdata.cc:372: "c->locks > 0" > 2021/11/16 17:40:44 kid1| assertion failed: cbdata.cc:115: "cookie == ((long)this ^ Cookie)" This is probably an unrelated bug. I recommend filing a bug report in Squid bugzilla and posting the corresponding "bt full" backtrace there. Alex. > -----Original Message----- > From: Alex Rousskov [mailto:rousskov@xxxxxxxxxxxxxxxxxxxxxxx] > Sent: Tuesday, November 16, 2021 3:42 PM > To: Lou?ansk? Luk??; Squid Users > Subject: Re: Too many ERROR: Collapsed forwarding queue > overflow for kid2 at 1024 items > > On 11/16/21 4:38 AM, Lou?ansk? Luk?? wrote: >> is it going to be patched only in the v6 version? > > I hope the existing fix applies to v5 cleanly, and I am ready to help with backporting if it does not. Beyond that, it is in the maintainer hands. I cannot predict whether or when the fix will be officially merged into v5 because I do not understand how those decisions are made. > > >> Anyway - in the morning I run debug with 20,9 to see: >> ... >> 2021/11/16 09:02:06.496 kid2| assertion failed: Transients.cc:221: "old == e" > > Unfortunately, I cannot see the cause of the assertion in this short/partial trace -- the problematic actions happened before the trace or were not logged during the trace. > > Patching your Squid with commit 5210df4 is the best next step IMO. If that patch does not help, then there are probably other bugs that we need to fix in v5 (at least). > > > HTH, > > Alex. > > >> -----Original Message----- >> From: Alex Rousskov [mailto:rousskov@xxxxxxxxxxxxxxxxxxxxxxx] >> Sent: Monday, November 15, 2021 5:17 PM >> To: Squid Users >> Cc: Lou?ansk? Luk?? >> Subject: Re: Too many ERROR: Collapsed forwarding queue >> overflow for kid2 at 1024 items >> >> On 11/15/21 7:43 AM, Lou?ansk? Luk?? wrote: >> >>> 2021/11/14 10:13:30 kid2| assertion failed: Transients.cc:221: "old == e" >>> 2021/11/15 08:37:36 kid2| assertion failed: Transients.cc:221: "old == e" >>> 2021/11/15 11:54:14 kid1| assertion failed: Transients.cc:221: "old == e" >>> 2021/11/15 12:16:27 kid1| assertion failed: Transients.cc:221: "old == e" >> >> I recommend ignoring queue overflows until the above assertions are fixed because worker deaths cause queue overflows. Your Squid is buggy, and those bugs essentially cause queue overflows. >> >> The assertion itself is known as Bug 5134: >> https://bugs.squid-cache.org/show_bug.cgi?id=5134 >> >> That bug has a speculative fix (master/v6 commit 5210df4). Please try it if you can. >> >> >> HTH, >> >> Alex. >> >> >>> -----Original Message----- >>> From: Alex Rousskov [mailto:rousskov@xxxxxxxxxxxxxxxxxxxxxxx] >>> Sent: Friday, November 12, 2021 5:24 PM >>> To: Lou?ansk? Luk??; squid-users@xxxxxxxxxxxxxxxxxxxxx >>> Subject: Re: Too many ERROR: Collapsed forwarding >>> queue overflow for kid2 at 1024 items >>> >>> On 11/11/21 10:19 AM, Lou?ansk? Luk?? wrote: >>> >>>> recently I'm facing too many ERROR: Collapsed forwarding queue >>>> overflow for kid2 at 1024 items lines in my Squid 5.2 log files. >>> >>> We see those overflows when kids die. Do you see any FATAL messages, assertions, or similar deadly errors in cache.log? >>> >>> >>>> Could someone elaborate how the queue is filled - what is clogging it? >>> >>> The sender/writer sends messages faster than the recipient/reader is >>> reading them, eventually exceeding the queue capacity (i.e. 1024 >>> messages). These messages are about Store entries that may need >>> synchronization across workers. Each message is very sm >> all. >>> >>> >>>> I don't mind too much if I have to turn collapsed forwarding off >>> >>> Most likely, the problem is not tied to collapsed forwarding. These >>> queues were used for collapsed forwarding when they were added, but >>> they are used for regular traffic as well in modern SMP Squids. We >>> need to change the queue names (and related code/m >> essage text) to reflect the expanded nature of these queues. >>> >>> >>> HTH, >>> >>> Alex. >>> ------------------------------ Message: 5 Date: Tue, 16 Nov 2021 13:23:00 -0500 From: Alex Rousskov <rousskov@xxxxxxxxxxxxxxxxxxxxxxx> To: squid-users@xxxxxxxxxxxxxxxxxxxxx Subject: Re: Multi-clients VPS - Authentication been shared. Message-ID: <7d3ac49b-d2f7-fffa-cb2d-e2377b8ada5e@xxxxxxxxxxxxxxxxxxxxxxx> Content-Type: text/plain; charset=windows-1252 On 11/16/21 11:53 AM, Graminsta wrote: > Hello friends, > > ? > > I'm using these user authentication lines in squid.conf based on > user?s authentication list: > > ? > > auth_param basic program /usr/lib/squid/basic_ncsa_auth > /etc/squid/users > > auth_param basic children 5 > > auth_param basic realm Squid proxy-caching web server > > auth_param basic credentialsttl 2 hours > > auth_param basic casesensitive off > > ? > > http_access allow localhost > > acl clientes proxy_auth REQUIRED > > http_access allow clientes > http_access deny !Safe_ports > http_access deny CONNECT !SSL_ports > http_access allow localhost manager > http_access deny manager > http_access deny all Please note that you are allowing authenticated clients to send traffic to unsafe ports. For example, they can CONNECT to non-SSL ports. You may want to reorder the above rules if that is not what you want. > #List of outgoings (all IPs are fake) > > http_port 181.111.11.111:4000 name=3 > acl ip3 myportname 3 > tcp_outgoing_address 2804:1934:2E1::3D6 ip3 > > ? > > http_port 181.111.11.112:4001 name=4 > acl ip4 myportname 4 > tcp_outgoing_address 2804:1934:3a8::3D7 ip4 > > ? > > The problem is that everyone whom is in the users file are allow to > use all tcp_outgoing_address. > > If a smarter client scans for open IPs and ports will be able to find > these outgoings. > > ? > > How can I restrict each user to their own tcp_outgoing_address output? I suspect you are asking the wrong question. A better question is "How do I restrict each user to their own http_port?". The answer is "Use http_access to deny authenticated users connected to wrong ports." However, you should also ask yourself another question: "Why am I using multiple http_ports if all I care about is who uses which tcp_outgoing_address?". The listening ports have virtually nothing to do with tcp_outgoing_address... I suspect you want something like this instead: http_port ... tcp_outgoing_address ...:3D01 user1 tcp_outgoing_address ...:3D02 user2 tcp_outgoing_address ...:3D03 user3 ... ...where userN is an ACL that matches an authenticated user N. HTH, Alex. ------------------------------ Subject: Digest Footer _______________________________________________ squid-users mailing list squid-users@xxxxxxxxxxxxxxxxxxxxx http://lists.squid-cache.org/listinfo/squid-users ------------------------------ End of squid-users Digest, Vol 87, Issue 19 ******************************************* _______________________________________________ squid-users mailing list squid-users@xxxxxxxxxxxxxxxxxxxxx http://lists.squid-cache.org/listinfo/squid-users
