On 11/18/21 3:54 PM, Graminsta wrote: > 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. This statement does not explain why you need multiple http_ports. > I have several customers per VPS. > Each one uses like 10 different ports to direct connections through > different IPv6s. These statements may conceal the answer, but I still do not understand why all your customers cannot use one IPv6 http_port. Please note that I am not saying that they can. I am only saying that it is not clear (to me) why you cannot simplify this configuration to one http_port. > 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? For each port X, you need to define an ACL that matches users that are allowed to use http_port X. I do not know how to do that exactly because I do not know what rules you use to make that decision -- these rules are specific to your business/application logic. Once you have that ACL, you only allow to-port-X traffic that matches it. Here is a sketch: http_port ... name=X http_port ... name=Y ... acl toPortX myportname X acl toPortX myportname Y ... acl allowedToUsePortX ... acl allowedToUsePortY ... ... http_access ... "standard" safety/admin rules here ... http_access allow toPortX allowedToUsePortX http_access allow toPortY allowedToUsePortY ... http_access deny all HTH, Alex. > -----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 > _______________________________________________ squid-users mailing list squid-users@xxxxxxxxxxxxxxxxxxxxx http://lists.squid-cache.org/listinfo/squid-users