Alex, If its not one issue its another. Now I can't seem to generate a cache log file for to to assist with further troubleshooting. I've restarted squid and used "squid -k reconfigure" a few times, verified debugging is enabled and set to "All,9", and I don't have any special rules in my config to point the cache log somewhere else. I'm not sure what I'm doing wrong with it. I did remove the file it created yesterday, because I wanted to make sure we had a fresh one to write to and send. I was thinking it may need explicit permissions to write the logs here but it didn't need that before and I'm not getting any errors related to it. The "access.log" file is still working, however. -----Original Message----- From: squid-users <squid-users-bounces@xxxxxxxxxxxxxxxxxxxxx> On Behalf Of Alex Rousskov Sent: Thursday, August 29, 2024 2:24 PM To: squid-users@xxxxxxxxxxxxxxxxxxxxx Subject: Re: Unable to access internal resources via hostname Caution: This email originated from outside of Hexcel. Do not click links or open attachments unless you recognize the sender and know the content is safe. On 2024-08-29 13:08, Piana, Josh wrote: > In regards to the debugging, do you still want me to do All,9 or is > All,6 acceptable? I am reading that 9 is... huge. I want ALL,9. I can usually handle its size. If you cannot, then adjust as needed, but my willingness to help will decrease (because it often takes me a lot longer to grok partial logs correctly). FWIW, the ALL,9 snippet size for a single-transaction test is usually quite manageable (under 1GB). > I did eventually find that it was the other log when I browsed /var/log/squid/... > The log was dated for today, which is good. But I'm not sure how to generate it on purpose? Squid writes to cache.log as it runs. You can remove the old log while Squid does not run and Squid will create a new file, or, better, look for "tail" hints on that FAQ page. When you run your test after configuring (and restarting) Squid with "debug_options ALL,9", Squid will write debugging info to its cache.log. There are more hints on that FAQ page. > Just so we're on the same understanding, I've only been using Linux > for 2 months, this project is my first experience with it. I do > apologize if I miss a lot of "common sense" stuff. This was tasked for > me to figure out and I've been having a pretty fun learning experience > so far. I sympathize, but do not have the time to offer enough guidance for basic sysadmin tasks. Others on the mailing list may be able to help with specific questions or, better, see if you can find a local Linux person who can help you with this task. If they know what they are doing, it should take them less than 30 minutes to produce the requested debugging cache.log snippet for the test transaction, even if they have never heard about Squid before. And you will learn a few new tricks... > I'll update those logs and wait for your response to this before > sending them or sending you a personal drop link. A link usually works best. Thank you, Alex. > -----Original Message----- > From: squid-users <squid-users-bounces@xxxxxxxxxxxxxxxxxxxxx> On > Behalf Of Alex Rousskov > Sent: Thursday, August 29, 2024 12:00 PM > To: squid-users@xxxxxxxxxxxxxxxxxxxxx > Subject: Re: Unable to access internal resources via > hostname > > Caution: This email originated from outside of Hexcel. Do not click links or open attachments unless you recognize the sender and know the content is safe. > > > On 2024-08-29 10:34, Piana, Josh wrote: > >> I've added the following to my squid.conf file # logformat custom >> %err_code/%err_detail # access_log daemon:/var/log/squid/access,log >> custom > > I assume you are using comment character (#) for email presentation purposes (i.e. it does not actually exist in your squid.conf). > > I assume that comma in your access log file name above is a typo that does not actually exist in your squid.conf. > > >> I'm not sure ... extra log details were added correctly > The above access_log configuration should reduce all access.log records to exactly two fields separated by a slash. Clearly, it does not! Thus, you are either not testing with the new configuration file (e.g., you have not fully shut down and then started Squid) or there are other serious problems (e.g., malformed squid.conf that confuses Squid v5). We should solve this mystery before moving any further. > > >> I've also enabled debugging options: >> # debug_options ALL,9 > > Thank you. Please note that this debugging info goes into cache.log, not access.log. I trust you have examined your cache.log for errors and warnings _before_ enabling debugging -- finding them among debugging noise can be challenging! ALL,9 debugging is for Squid developers to study. > > My recommendation for the next step remains the same. Look for "The best option" in my previous response. > > > HTH, > > Alex. > > >> I've also cleaned up our ACL's to better reflect what is going on: >> # acl src_self src 127.0.0.0/8 >> # acl src_self src 10.46.11.69 >> # acl dst_self dst 127.0.0.0/8 >> # acl dst_self dst 10.46.11.69 >> >> # acl from_arc src 10.46.0.0/15 >> >> # acl local_dst_addr dst 10.0.0.0/8 >> # acl local_dst_addr dst 172.0.0.0/8 >> >> When accessing internal devices via IP, it works. >> I think this is because of this ACL: >> # http_access allow local_dst_addr >> # http_reply_access allow local_dst_addr >> >> But when I access those same internal devices via hostname, it fails. >> I'm using this ACL, which I just created a separate file for: >> acl local_dst_dom dstdomain "etc/squid/local_dst_dom" >> http_access allow local_dst_dom >> http_reply_access allow local_dst_dom >> >> I added an ACL file because I figure it will be more extensive than the more simple IP range ACL's. >> I've added a few local websites to the "local_dst_dom" list, but I'm unable to get this to resolve without using IP. >> >> For instance: "https://hexcelssp/" is the name of one of our internal websites for our company. >> This doesn't load under our current config but "https://10.96.14.174/" DOES load. >> >> I've added "hexnt2067" as well, which you can see me testing in the below logs. >> Again, this DOES work with its IP, 10.96.102.67. >> >> I'm not getting a proxy error message when I try to browse to that URL though, we just can't reach it. >> >> Here's the log results after enabling debugging and better log features: >> >> 29/Aug/2024:10:25:33 -0400.380 10.46.49.190 TCP_DENIED/407 4132 >> CONNECT hexcelssp:443 - HIER_NONE/- text/html >> 29/Aug/2024:10:25:33 -0400.515 10.46.49.190 NONE_NONE/500 0 CONNECT >> hexcelssp:443 JPIANA@AD.<DOMAIN>.COM HIER_NONE/- - >> 29/Aug/2024:10:25:39 -0400.799 10.46.49.190 TCP_TUNNEL/200 11716 >> CONNECT contile.services.mozilla.com:443 JPIANA@AD.<DOMAIN>.COM >> HIER_DIRECT/34.117.188.166 - >> 29/Aug/2024:10:26:05 -0400.507 10.46.49.190 TCP_DENIED/407 4474 GET >> http://hexnt2067/sites/it/help/SitePages/Home.aspx - HIER_NONE/- >> text/html >> 29/Aug/2024:10:26:05 -0400.646 10.46.49.190 TCP_MISS/500 8320 GET >> http://hexnt2067/sites/it/help/SitePages/Home.aspx >> JPIANA@AD.<DOMAIN>.COM HIER_NONE/- text/html >> 29/Aug/2024:10:26:05 -0400.735 10.46.49.190 TCP_DENIED/403 4440 GET >> http://arcga/ >> te2.ad%2F&data=05%7C02%7Cjosh.piana%40hexcel.com%7Ce66ed645b81f49d475 >> d >> e08dcc843a4a6%7C4248050df19546d5ac9c0c7c52b04cae%7C0%7C0%7C6386054400 >> 7 >> 1382901%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiL >> C >> JBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=xqwHdvSxDiifEZVJALLtc >> C >> 6L9VoLptjKTHgDVTNBzLY%3D&reserved=0.<domain>.com:8080/squid-internal- >> s tatic/icons/SN.png - HIER_NONE/- text/html >> 29/Aug/2024:10:26:05 -0400.779 10.46.49.190 TCP_MISS_ABORTED/500 0 >> GET http://hexnt2067/favicon.ico JPIANA@AD.<DOMAIN>.COM HIER_NONE/- >> text/html >> 29/Aug/2024:10:27:13 -0400.036 10.46.49.190 TCP_DENIED/407 4474 GET >> http://hexnt2067/sites/it/help/SitePages/Home.aspx - HIER_NONE/- >> text/html >> 29/Aug/2024:10:27:13 -0400.227 10.46.49.190 TCP_MISS/500 8334 GET >> http://hexnt2067/sites/it/help/SitePages/Home.aspx >> JPIANA@AD.<DOMAIN>.COM HIER_NONE/- text/html >> 29/Aug/2024:10:27:13 -0400.302 10.46.49.190 TCP_DENIED/403 4440 GET >> http://arcga/ >> te2.ad%2F&data=05%7C02%7Cjosh.piana%40hexcel.com%7Ce66ed645b81f49d475 >> d >> e08dcc843a4a6%7C4248050df19546d5ac9c0c7c52b04cae%7C0%7C0%7C6386054400 >> 7 >> 1382901%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiL >> C >> JBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=xqwHdvSxDiifEZVJALLtc >> C >> 6L9VoLptjKTHgDVTNBzLY%3D&reserved=0.<domain>.com:8080/squid-internal- >> s tatic/icons/SN.png - HIER_NONE/- text/html >> 29/Aug/2024:10:27:17 -0400.376 10.46.49.190 TCP_DENIED/407 4132 >> CONNECT hexcelssp:443 - HIER_NONE/- text/html >> 29/Aug/2024:10:27:17 -0400.514 10.46.49.190 NONE_NONE/500 0 CONNECT >> hexcelssp:443 JPIANA@AD.<DOMAIN>.COM HIER_NONE/- - >> >> I'm not sure the debugging and extra log details were added correctly, because these look the same. >> >> Thanks, >> Josh >> >> >> -----Original Message----- >> From: squid-users <squid-users-bounces@xxxxxxxxxxxxxxxxxxxxx> On >> Behalf Of Alex Rousskov >> Sent: Wednesday, August 28, 2024 4:01 PM >> To: squid-users@xxxxxxxxxxxxxxxxxxxxx >> Subject: Re: Unable to access internal resources via >> hostname >> >> Caution: This email originated from outside of Hexcel. Do not click links or open attachments unless you recognize the sender and know the content is safe. >> >> >> On 2024-08-28 15:25, Piana, Josh wrote: >> >>> I now understand that Squid 5.5 ... is actually out of date as well. >>> I regret installing and working off of this because I jused assumed >>> the "yum" install command for the Squid distro would give me the >>> most recent, known-good, software. That's completely on me. >> >> Whether yum install installs something production-worthy today is between you and your Linux distro. Squid Project volunteers, including me, do no control what distribution you pick and what that distribution ships. The reason I mentioned v5 support status is to avoid creating a false impression that there are no _other_ (i.e. unreported by you on this thread) problems you may want to know about and to lower your expectations from the level of support you may get from Squid Project volunteers like me. >> >> Said that, I doubt the problem you are trying to solve is v5-specific. >> You may get better diagnostics if you run v6+, and you may receive fewer unusable (with v5) instructions if you run v6+, but the problem is likely to be present in a v6-based setup as well. >> >> >>> From how I understand it, his intentions for internal users >>> accessing internal resources, would skip authentication altogether. >> >> I assume that the problematic test that you want to fix is done using >> "internal users". You have already stated that the test is accessing >> "internal resources". Yet, we see that Squid asks the test client to >> authenticate (TCP_DENIED/407). Thus, >> >> * either local_dst_dom, local_dst_addr, and authless_src ACLs do not >> match test client transactions >> >> * or there is an authentication-triggering directive (e.g., "http_access deny block_user") located above a matching "http_access allow" rule that uses one of those ACLs three. >> >> Ideally, we should figure out which http_access rule matches the problematic transaction and triage from there. Unfortunately, Squid does not make that basic task easy. The best option I can think of is for you to share (privately if needed to avoid publishing sensitive info) a pointer to compressed cache.log file collected while reproducing the problem using a single test transaction after setting debug_options to ALL,9. Squid FAQ has a few hints about collecting relevant info: >> https://wiki/ >> .squid-cache.org%2FSquidFaq%2FBugReporting%23debugging-a-single-trans >> a >> ction&data=05%7C02%7Cjosh.piana%40hexcel.com%7Ce66ed645b81f49d475de08 >> d >> cc843a4a6%7C4248050df19546d5ac9c0c7c52b04cae%7C0%7C0%7C63860544007138 >> 2 >> 901%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBT >> i >> I6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=RDkHh9Xa1Iyi3jC%2FbPGaoJo >> I >> %2FPvayueaofn8FRmb4KQ%3D&reserved=0 >> >> This "unexpected authentication" mystery may not be directly related to the "HTTP 500 error responses" mystery we discussed earlier, but it may help to fix authentication first. >> >> >> HTH, >> >> Alex. >> >> >>> Here's a small piece, with his notes included, of why I think that. >>> >>> -------------------------------------------------------------------- >>> - >>> - >>> -------------------------------------------------- >>> # >>> -------------------------------------------------------------------- >>> - >>> - >>> ------ >>> # allow without authentication >>> # these rules allow certain connects without user authentication # >>> these allow any protocol/method/etc >>> >>> # ***** IMPORTANT ***** >>> # Adding to these lists also exempts from all content filtering. >>> # In particular, executables will be allowed to download! >>> # ***** IMPORTANT ***** >>> >>> # allow connects to local destinations without authentication # by >>> domain name from URL >>> http_access allow local_dst_dom >>> http_reply_access allow local_dst_dom >>> >>> # by IP address name resolves to >>> http_access allow local_dst_addr >>> http_reply_access allow local_dst_addr >>> -------------------------------------------------------------------- >>> - >>> - >>> -------------------------------------------------- >>> >>> The "http_access allow local_dst_dom" and the following reply statement seems to point toward his intentions when writing this. >>> >>> The only thing in the old config this was referencing was this, and to me, it doesn't make sense: >>> # acl local_dst_dom dstdomain arcgate >>> >>> It's worth noting that despite how awkward this seems, it DOES work. On the old web proxy we're currently still running live. >>> >>> I've gone as far as swapping out just the authentication settings and keeping the entire old config, but it still doesn't work. >>> I've setup a realmd/sssd/kerberos backend instead of Samba/Windbind that the old server uses. >>> >>> To state the issue we're having again - internal resources connecting to other internal resources fails via hostname, but works when using IP. I was able to troubleshoot and conclude DNS was not the issue, as all other aspects are working as intended and they certainly do use DNS. Also pings resolve using hostname from the new squidbox so that implies that DNS is working as expected. >>> >>> Ultimately, here's what I think we want, please feel free to poke holes in it: >>> Allow clients who are accessing other internal rersources to be able to browse to it using its hostname, without needing authentication first. >>> >>> >>> I do intend on adding those parameters you mentioned to the logs so I can get better details within. I also need to look into how to use the debugging features, I'm not familiar with it at all. >>> >>> I apologize for the wall of text, looking forward to what you guys have to say about this. >>> >>> Thanks, >>> Josh >>> >>> -----Original Message----- >>> From: squid-users <squid-users-bounces@xxxxxxxxxxxxxxxxxxxxx> On >>> Behalf Of Alex Rousskov >>> Sent: Wednesday, August 28, 2024 2:31 PM >>> To: squid-users@xxxxxxxxxxxxxxxxxxxxx >>> Subject: Re: Unable to access internal resources via >>> hostname >>> >>> Caution: This email originated from outside of Hexcel. Do not click links or open attachments unless you recognize the sender and know the content is safe. >>> >>> >>> On 2024-08-28 14:18, Alex Rousskov wrote: >>>> On 2024-08-28 11:24, Piana, Josh wrote: >>>> >>>>> Here's the log and (I think) relevant ACL's? >>>> >>>> According to your access.log, Squid denies problematic CONNECT >>>> requests with HTTP 407 errors responses. Usually, that means those >>>> requests match an "http_access deny" rule. Clearly, you expect an >>>> "allow" outcome instead, but it is difficult (for me) to figure out >>>> where your expectations mismatch reality; there are no rules that >>>> explicitly mention hexcelssp domain, for example: Which >>>> "http_access allow" rule do you expect those denied requests to match? >>> >>> Sorry, I probably misinterpreted those access.log records: It looks like the denied (TCP_DENIED/407) access is something you actually expect because you want that test request to be authenticated. The client supplies the necessary credentials in the second request, and then that second request fails with a (rather generic) HTTP 500 error code, without contacting the origin server. >>> >>> I am guessing that you are concerned about that second request/transaction rather than the first one. >>> >>> Squid generates HTTP 500 errors for a variety of different reasons. Are there any messages in cache.log (at default debugging level) that correspond to these failing test transactions? If there are none, please add %err_code/%err_detail to your access_log logformat so that Squid logs more information about the problem to access.log (see logformat and access_log directives in squid.conf.documented for details). >>> >>> >>> Thank you, >>> >>> Alex. >>> >>> >>> >>>> Also, does mgr:ipcache cache manager query confirm that Squid has >>>> read your /etc/hosts file and cached the record you expect it to use? >>>> >>>> Alex. >>>> >>>> >>>>> ------------------------------------------------------------------ >>>>> - >>>>> - >>>>> - >>>>> -------------------------------------- >>>>> # /var/log/squid/access.log results for internal conflicts >>>>> >>>>> 28/Aug/2024:10:57:17 -0400.234 10.46.49.190 TCP_DENIED/407 4132 >>>>> CONNECT hexcelssp:443 - HIER_NONE/- text/html >>>>> 28/Aug/2024:10:57:17 -0400.253 10.46.49.190 NONE_NONE/500 0 >>>>> CONNECT >>>>> hexcelssp:443 JPIANA@AD.<DOMAIN>.COM HIER_NONE/- - >>>>> 28/Aug/2024:10:57:17 -0400.380 10.46.49.190 TCP_DENIED/407 4132 >>>>> CONNECT hexcelssp:443 - HIER_NONE/- text/html >>>>> 28/Aug/2024:10:57:17 -0400.399 10.46.49.190 NONE_NONE/500 0 >>>>> CONNECT >>>>> hexcelssp:443 JPIANA@AD.<DOMAIN>.COM HIER_NONE/- - >>>>> ------------------------------------------------------------------ >>>>> - >>>>> - >>>>> - >>>>> -------------------------------------- >>>>> >>>>> # acl all src all >>>>> >>>>> acl src_self src 127.0.0.0/8 >>>>> acl src_self src 10.46.11.69 >>>>> >>>>> acl dst_self dst 127.0.0.0/8 >>>>> acl dst_self dst 10.46.11.69 >>>>> >>>>> acl from_arc src 10.46.0.0/15 >>>>> >>>>> acl local_dst_addr dst 10.0.0.0/8 >>>>> acl local_dst_addr dst 172.0.0.0/8 acl local_dst_addr dst >>>>> bldg3.<domain>.com acl local_dst_addr dst bldg5.<domain>.com >>>>> >>>>> # these keep URLs of popular local servers from being forwarded >>>>> acl local_dst_dom dstdomain arcgate >>>>> >>>>> # allow connects to local destinations without authentication # by >>>>> domain name from URL >>>>> http_access allow local_dst_dom >>>>> http_reply_access allow local_dst_dom >>>>> >>>>> # by IP address name resolves to >>>>> http_access allow local_dst_addr >>>>> http_reply_access allow local_dst_addr >>>>> >>>>> # allow trusted hosts without authentication # these are just ip's >>>>> on the 10.46.11.x network acl authless_src src "/etc/squid/authless_src" >>>>> http_access allow authless_src >>>>> http_reply_access allow authless_src >>>>> ------------------------------------------------------------------ >>>>> - >>>>> - >>>>> - >>>>> -------------------------------------- >>>>> >>>>> -----Original Message----- >>>>> From: squid-users <squid-users-bounces@xxxxxxxxxxxxxxxxxxxxx> On >>>>> Behalf Of Matus UHLAR - fantomas >>>>> Sent: Wednesday, August 28, 2024 10:47 AM >>>>> To: squid-users@xxxxxxxxxxxxxxxxxxxxx >>>>> Subject: Re: Unable to access internal resources via >>>>> hostname >>>>> >>>>> Caution: This email originated from outside of Hexcel. Do not >>>>> click links or open attachments unless you recognize the sender >>>>> and know the content is safe. >>>>> >>>>> >>>>> On 28.08.24 14:20, Piana, Josh wrote: >>>>>> Hello Squid Support, >>>>> >>>>> This squid user forum FYI >>>>> >>>>>> We are unable to get to internal resources via hostname but using >>>>>> the IP address works fine. Immediately, I thought this was DNS >>>>>> but when I checked the /etc/resolv.conf/ file it was pointing >>>>>> correctly to our Windows DNS server and we can ping all devices >>>>>> using their hostname, just not when browsing to it. This leads >>>>>> me to believe something may be wrong with our squid config. >>>>> >>>>> hard to guess without seeing logs or ACL's. >>>>> >>>>> >>>>> -- >>>>> Matus UHLAR - fantomas, uhlar@xxxxxxxxxxx ; http://www/. >>>>> fantomas.sk%2F&data=05%7C02%7Cjosh.piana%40hexcel.com%7C2db72264ca >>>>> a >>>>> 0 >>>>> 4 >>>>> f1fd80d08dcc78f9245%7C4248050df19546d5ac9c0c7c52b04cae%7C0%7C0%7C6 >>>>> 3 >>>>> 8 >>>>> 6 >>>>> 04666668859787%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjo >>>>> i >>>>> V >>>>> 2 >>>>> luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=Z7cUEdNvIn >>>>> D >>>>> A >>>>> J >>>>> PwgQJhXWSK3H2mkAPe4CNcfYJFyy6M%3D&reserved=0 >>>>> Warning: I wish NOT to receive e-mail advertising to this address. >>>>> Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu. >>>>> It's now safe to throw off your computer. >>>>> _______________________________________________ >>>>> squid-users mailing list >>>>> squid-users@xxxxxxxxxxxxxxxxxxxxx >>>>> https://lis/ >>>>> ts.squid-cache.org%2Flistinfo%2Fsquid-users&data=05%7C02%7Cjosh.pi >>>>> a >>>>> n >>>>> a >>>>> %40hexcel.com%7C2db72264caa04f1fd80d08dcc78f9245%7C4248050df19546d >>>>> 5 >>>>> a >>>>> c >>>>> 9c0c7c52b04cae%7C0%7C0%7C638604666674016161%7CUnknown%7CTWFpbGZsb3 >>>>> d >>>>> 8 >>>>> e >>>>> yJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D% >>>>> 7 >>>>> C >>>>> 0 >>>>> %7C%7C%7C&sdata=%2B%2B7inZxg2LEmB2KFVWmtn64FG8SwHpEZeEyAjhNClnU%3D >>>>> & >>>>> r >>>>> e >>>>> served=0 _______________________________________________ >>>>> squid-users mailing list >>>>> squid-users@xxxxxxxxxxxxxxxxxxxxx >>>>> https://lis/ >>>>> ts.squid-cache.org%2Flistinfo%2Fsquid-users&data=05%7C02%7Cjosh.pi >>>>> a >>>>> n >>>>> a >>>>> %40hexcel.com%7C2db72264caa04f1fd80d08dcc78f9245%7C4248050df19546d >>>>> 5 >>>>> a >>>>> c >>>>> 9c0c7c52b04cae%7C0%7C0%7C638604666674016161%7CUnknown%7CTWFpbGZsb3 >>>>> d >>>>> 8 >>>>> e >>>>> yJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D% >>>>> 7 >>>>> C >>>>> 0 >>>>> %7C%7C%7C&sdata=%2B%2B7inZxg2LEmB2KFVWmtn64FG8SwHpEZeEyAjhNClnU%3D >>>>> & >>>>> r >>>>> e >>>>> served=0 >>>> >>>> _______________________________________________ >>>> squid-users mailing list >>>> squid-users@xxxxxxxxxxxxxxxxxxxxx >>>> https://list/ >>>> s.squid-cache.org%2Flistinfo%2Fsquid-users&data=05%7C02%7Cjosh.pian >>>> a >>>> % >>>> 4 >>>> 0hexcel.com%7C2db72264caa04f1fd80d08dcc78f9245%7C4248050df19546d5ac >>>> 9 >>>> c >>>> 0 >>>> c7c52b04cae%7C0%7C0%7C638604666674016161%7CUnknown%7CTWFpbGZsb3d8ey >>>> J >>>> W >>>> I >>>> joiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7 >>>> C >>>> % >>>> 7 >>>> C%7C&sdata=%2B%2B7inZxg2LEmB2KFVWmtn64FG8SwHpEZeEyAjhNClnU%3D&reser >>>> v >>>> e >>>> d >>>> =0 >>> >>> _______________________________________________ >>> squid-users mailing list >>> squid-users@xxxxxxxxxxxxxxxxxxxxx >>> https://list/ >>> s.squid-cache.org%2Flistinfo%2Fsquid-users&data=05%7C02%7Cjosh.piana >>> % >>> 4 >>> 0hexcel.com%7C6f7f2ea035ca4506507008dcc79c3598%7C4248050df19546d5ac9 >>> c >>> 0 >>> c7c52b04cae%7C0%7C0%7C638604720952164544%7CUnknown%7CTWFpbGZsb3d8eyJ >>> W >>> I >>> joiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C >>> % >>> 7 >>> C%7C&sdata=RrdtLQu5y421WIi6vjyxj1ZsNRdIn%2FMaKusbjKGoY48%3D&reserved >>> = >>> 0 _______________________________________________ >>> squid-users mailing list >>> squid-users@xxxxxxxxxxxxxxxxxxxxx >>> https://list/ >>> s.squid-cache.org%2Flistinfo%2Fsquid-users&data=05%7C02%7Cjosh.piana >>> % >>> 4 >>> 0hexcel.com%7C6f7f2ea035ca4506507008dcc79c3598%7C4248050df19546d5ac9 >>> c >>> 0 >>> c7c52b04cae%7C0%7C0%7C638604720952164544%7CUnknown%7CTWFpbGZsb3d8eyJ >>> W >>> I >>> joiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C >>> % >>> 7 >>> C%7C&sdata=RrdtLQu5y421WIi6vjyxj1ZsNRdIn%2FMaKusbjKGoY48%3D&reserved >>> = >>> 0 >> >> _______________________________________________ >> squid-users mailing list >> squid-users@xxxxxxxxxxxxxxxxxxxxx >> https://list/ >> s.squid-cache.org%2Flistinfo%2Fsquid-users&data=05%7C02%7Cjosh.piana% >> 4 >> 0hexcel.com%7Ce66ed645b81f49d475de08dcc843a4a6%7C4248050df19546d5ac9c >> 0 >> c7c52b04cae%7C0%7C0%7C638605440071382901%7CUnknown%7CTWFpbGZsb3d8eyJW >> I >> joiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C% >> 7 >> C%7C&sdata=1PZUcTcTx39ZCH76h1BVemyFSPKN6R%2B7%2F%2FJ3XEqoSFQ%3D&reser >> v >> ed=0 _______________________________________________ >> squid-users mailing list >> squid-users@xxxxxxxxxxxxxxxxxxxxx >> https://list/ >> s.squid-cache.org%2Flistinfo%2Fsquid-users&data=05%7C02%7Cjosh.piana% >> 4 >> 0hexcel.com%7Ce66ed645b81f49d475de08dcc843a4a6%7C4248050df19546d5ac9c >> 0 >> c7c52b04cae%7C0%7C0%7C638605440071382901%7CUnknown%7CTWFpbGZsb3d8eyJW >> I >> joiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C% >> 7 >> C%7C&sdata=1PZUcTcTx39ZCH76h1BVemyFSPKN6R%2B7%2F%2FJ3XEqoSFQ%3D&reser >> v >> ed=0 > > _______________________________________________ > squid-users mailing list > squid-users@xxxxxxxxxxxxxxxxxxxxx > https://list/ > s.squid-cache.org%2Flistinfo%2Fsquid-users&data=05%7C02%7Cjosh.piana%4 > 0hexcel.com%7C56fa965859a74d555dd708dcc857beed%7C4248050df19546d5ac9c0 > c7c52b04cae%7C0%7C0%7C638605526440153938%7CUnknown%7CTWFpbGZsb3d8eyJWI > joiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7 > C%7C&sdata=%2FpJeOC4wFdRLuaSSxriBI91J7OzBqPA71dCz%2BDkITIg%3D&reserved > =0 _______________________________________________ > squid-users mailing list > squid-users@xxxxxxxxxxxxxxxxxxxxx > https://list/ > s.squid-cache.org%2Flistinfo%2Fsquid-users&data=05%7C02%7Cjosh.piana%4 > 0hexcel.com%7C56fa965859a74d555dd708dcc857beed%7C4248050df19546d5ac9c0 > c7c52b04cae%7C0%7C0%7C638605526440310231%7CUnknown%7CTWFpbGZsb3d8eyJWI > joiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7 > C%7C&sdata=86Jd4eCPBOi8EbFA2d79Jg2ErbDJn5cmtOFwh2c5cA4%3D&reserved=0 _______________________________________________ squid-users mailing list squid-users@xxxxxxxxxxxxxxxxxxxxx https://lists.squid-cache.org/listinfo/squid-users _______________________________________________ squid-users mailing list squid-users@xxxxxxxxxxxxxxxxxxxxx https://lists.squid-cache.org/listinfo/squid-users