Kenneth,
I found your problem, because I was just literally able to replicate your problem on my production IPFire. Figured it was Off-Peak hours so I could toy with it slightly.
Lets do show and tell here…
Here is what I was able to force to happen, on my working system.
Quick test to see login passwords… See notes in green on picture…
I added a password after testing to the passwords box on the IPFire Web Proxy screen… This is where I figured out what I believe to be your problem, based on testing and reading back through your posts.
What did I do to cause this? I added a password to this box.
I clicked “Save and Restart” button on the same page to recycle squid services and re-read config.
After doing so, I closed my browser tabs, went back to the cachemanager login page, and tried logging in with crap passwords again, and it blocked me.
Each time I changed the password, I run:
cat squid.conf to see if the password was updating. Sure was…
Go check out your GUI and your squid.conf and look for your password:
cachemgr_passwd Hawaii all
I took it a little further in testing… Toying more, and found exactly your problem… Now I am pretty damn sure I hit the bullseye…
the URI rotate, and every other URI path under the cache manager started failing
cache_object://x,x,x.1/via_headers for example…
and…drumroll please… The problem is…
There is a password in the Web Proxy field, just below the email you entered. Delete that password, Click “Save and Restart”, then empty your cache, close your browser, open it back up and try it again. Almost positive it will work!
I told you in the beginning that I had seen this happen to me in the past and it took me this long to figure it back out, because I just couldn’t remember. There is something jacked up in the squid proxy code that if you have a password in there, it will allow you to the cache manager menu but will choke on all of its URI paths.
Give that a shot and see what happens!
Eric