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
