Re: [squid-dev] Drop cache_object protocol support
On 25.01.2023 16:58, Eduard Bagdasaryan wrote: On 25.01.2023 15:29, Amos Jeffries wrote: On 25/01/2023 5:34 pm, Alex Rousskov wrote: On 1/24/23 20:57, Amos Jeffries wrote: Blocker #1: The cachemgr_passwd directly still needs to be cleanly removed, eg replaced by a manager_access ACL based mechanism. I do not see a relationship: I have not tested it, but the existing CacheManager::ParseHeaders() code already extracts authentication information from cache manager requests that use "http" scheme AFAICT. Can you detail why the cachemgr_passwd directive/code cannot continue to work essentially as it works today after cache_object scheme support is removed from Squid? We should check that then. It may not be as impactful as I am recalling. My test showed that CacheManager::ParseHeaders() extracts password from the Authorization header incorrectly: params.password gets an extra '\n' symbol and CacheManager::CheckPassword() fails. This, however, seems easy to fix. My previous test was incorrect - please ignore this comment. I retested it with a properly encoded base64 password now. Eduard. ___ squid-dev mailing list squid-dev@lists.squid-cache.org http://lists.squid-cache.org/listinfo/squid-dev
Re: [squid-dev] Drop cache_object protocol support
On 1/25/23 07:29, Amos Jeffries wrote: On 25/01/2023 5:34 pm, Alex Rousskov wrote: On 1/24/23 20:57, Amos Jeffries wrote: Blocker #2: The squidclient tool still sends cache_object: scheme when given "mgr:" on the CLI. We need to upgrade that first Looks like we are in agreement on that. and allow admin some time to upgrade before removing the scheme support in squid itself. Agreed. Would six months be enough in your opinion? If yes, we may be able to remove cache_object support in v6. Otherwise, we can remove cache_object support starting with v7 (as far as numbered releases are concerned). v6 will "feature freeze" in 10 days. With proper cooperation, 10 days is more than enough to remove cache_object support, but I am not going to fight for that given your resistance. Early in v7 cycle should be good. Unless you stop me, I will post a message to squid-users to warn the admins that they should not count on Squid instances supporting cache_object scheme in v7 releases. IMO, we should not keep any code that is only needed for Squid v3.1 and earlier. Squid v3.2 and later should http-based cache manager access, right? More code always means more maintenance overheads and higher change costs. Given our lack of resources, we should start ignoring Squid v3 needs. In sentiment I agree. In practicality we have to cope with "LTS" from vendors, and Squid bugs in the manager. IMO, LTS vendors and old Squid bugs do not prevent us from removing cache_object support from cachemgr.cgi: The number of admins that match _all_ of the conditions listed below at the same time is negligible. We should not spend our resources "coping" with those esoteric cases. 1. Use Squid v3. 2. Use Squid v7. 3. Use cachemgr.cgi to manage both Squid versions. 4. Cannot use cachemgr.cgi from Squid v6. 5. Cannot patch cachemgr.cgi v7 to restore cache_object support. v3.2 has http: but the https:, ftp:, whois:, gopher: schemes were broken until late in the v3.5 series backports. So going by [1] LTS systems still using v3.2 are still a pain. We can stop that pain any time we want. All it takes is for us to stop mentioning v3 releases when making design decisions like this one. We _choose_ to prolong that pain and to spend scarce resources on a negligible percentage of unimportant use cases instead of spending those resources on popular and important use cases. For completeness, that MGR_INDEX regression you fixed a short while ago also means some broken v4/v5 releases may be a pain source during the transition. Those releases should not be considered a pain in this context because if that bug is actually important, it will be fixed in those releases. The longer we wait on removal from the CGI and CLI tools (only) the more seamless it goes. So I am inclined to be very conservative on the tools capability removal and proactive on ensuring they can cope with the squid capability loss. And since there is no way to actually measure "more seamless" or to prove that we are wasting resources on rare unimportant use cases, we end up doing what we do best -- increasing and prolonging pain. Alex. ___ squid-dev mailing list squid-dev@lists.squid-cache.org http://lists.squid-cache.org/listinfo/squid-dev
Re: [squid-dev] Drop cache_object protocol support
On 25.01.2023 15:29, Amos Jeffries wrote: On 25/01/2023 5:34 pm, Alex Rousskov wrote: On 1/24/23 20:57, Amos Jeffries wrote: Blocker #1: The cachemgr_passwd directly still needs to be cleanly removed, eg replaced by a manager_access ACL based mechanism. I do not see a relationship: I have not tested it, but the existing CacheManager::ParseHeaders() code already extracts authentication information from cache manager requests that use "http" scheme AFAICT. Can you detail why the cachemgr_passwd directive/code cannot continue to work essentially as it works today after cache_object scheme support is removed from Squid? We should check that then. It may not be as impactful as I am recalling. My test showed that CacheManager::ParseHeaders() extracts password from the Authorization header incorrectly: params.password gets an extra '\n' symbol and CacheManager::CheckPassword() fails. This, however, seems easy to fix. Eduard. ___ squid-dev mailing list squid-dev@lists.squid-cache.org http://lists.squid-cache.org/listinfo/squid-dev
Re: [squid-dev] Drop cache_object protocol support
On 25/01/2023 5:34 pm, Alex Rousskov wrote: On 1/24/23 20:57, Amos Jeffries wrote: Blocker #1: The cachemgr_passwd directly still needs to be cleanly removed, eg replaced by a manager_access ACL based mechanism. I do not see a relationship: I have not tested it, but the existing CacheManager::ParseHeaders() code already extracts authentication information from cache manager requests that use "http" scheme AFAICT. Can you detail why the cachemgr_passwd directive/code cannot continue to work essentially as it works today after cache_object scheme support is removed from Squid? We should check that then. It may not be as impactful as I am recalling. Blocker #2: The squidclient tool still sends cache_object: scheme when given "mgr:" on the CLI. We need to upgrade that first Looks like we are in agreement on that. and allow admin some time to upgrade before removing the scheme support in squid itself. Agreed. Would six months be enough in your opinion? If yes, we may be able to remove cache_object support in v6. Otherwise, we can remove cache_object support starting with v7 (as far as numbered releases are concerned). v6 will "feature freeze" in 10 days. That 6 months beta period is for proving the v6 behaviour changes work properly. Not for adding new behaviour, especially any cause of admin annoyance. IMO what we have been discussing is far enough into new feature territory to be a "no" for v6 backport. Specific patches may get a different answer, but the whole change is unlikely. Early in v7 cycle should be good. cachemgr.cgi should already prefer http(s) and only use cache_object as a backup. IMO the CGI tool should stay that way, supporting the scheme for older installations even after we drop it from the rest of Squid. IMO, we should not keep any code that is only needed for Squid v3.1 and earlier. Squid v3.2 and later should http-based cache manager access, right? More code always means more maintenance overheads and higher change costs. Given our lack of resources, we should start ignoring Squid v3 needs. In sentiment I agree. In practicality we have to cope with "LTS" from vendors, and Squid bugs in the manager. v3.2 has http: but the https:, ftp:, whois:, gopher: schemes were broken until late in the v3.5 series backports. So going by [1] LTS systems still using v3.2 are still a pain. For completeness, that MGR_INDEX regression you fixed a short while ago also means some broken v4/v5 releases may be a pain source during the transition. The longer we wait on removal from the CGI and CLI tools (only) the more seamless it goes. So I am inclined to be very conservative on the tools capability removal and proactive on ensuring they can cope with the squid capability loss. I would schedule the squid binary cleanup for v7 and the admin tools for v8 at earliest (4 years of v3.2 LTS pain). Moreover, I do not see how we can keep that "backup" code while supporting newer Squids and Javascript-disabled browsers at the same time: AFAICT, when Javascript is disabled (or not working properly), that "only as a backup" code will send cache_object requests to modern Squids that will no longer support them... That would be a serious bug. It breaks admin ability to manage proxies newer than their web server installation - which is more likely to be running outdated LTS than the proxy servers. I think we should upgrade that cachemgr.cgi code rather than preserve it for Squid v3 needs. However, if you insist, it will stay simply because I do not think cachemgr.cgi is worth our time. [1] My records of what vendors are providing as of Nov 2022 indicate that: * v5, v4, and v3.5 are currently being shipped in new installs. * v3.4 and v3.2 are still in popular 5-10 year old machinery due to vendor LTS. * other Squid versions were effectively non-existent. HTH Amos ___ squid-dev mailing list squid-dev@lists.squid-cache.org http://lists.squid-cache.org/listinfo/squid-dev
