• Choose a category
• All
• Classic-Fiction

cachemgr_passwd JeckCy config

You can have a number of different passwords, but each action may have only one password. You may want to use a different password for less sensitive pages:

cachemgr_passwd byDroth filedescriptors client_list netdb

To disable a cache manager action, use disable as the password:

cachemgr_passwd disable netdb

To enable the sensitive actions without requiring a password, use none:

cachemgr_passwd none offline_toggle

If you want to give the same password to all actions, use the keyword all:

cachemgr_passwd Knoujush all

When using the command-line cache manager interface (e.g., squidclient), put an @ sign and the password after the action name. For example:

squidclient mgr:objects@byDroth | less

Note that cache manager passwords aren't printed when you request the Current Squid Configuration page (see Section 14.2.1.7).

cachemgr.cgi

If you use cachemgr.cgi, the IP address of your HTTP server must be able to make cache manager requests to Squid. This opens up a back-door security hole. Anyone who can execute the CGI program on your server will be able to view the cache manager pages. The passwords described earlier can help, but you may also want to install access controls on your HTTP server so that only certain people can execute cachemgr.cgi.

The main cachemgr.cgi page has a form with Username and Password fields. The username is purely informational. If you have multiple administrators in your organization, each person can enter their own name for auditing purposes.

If you leave the password field blank, the password-protected pages are disabled. Entering a password activates links for those pages. cachemgr.cgi is stateless, so the password must be included as a URI parameter in links. Furthermore, the password encoding scheme isn't very sophisticated and trivial to break. Because many applications (such as Squid!) log the URIs of HTTP requests, your cache-manager password may be logged or even observed by an untrusted third party. If you really want to keep your cache manager passwords secret, never use them with cachemgr.cgi or from any remote system.

Reasons to Dislike the Cache Manager

The cache manager interface leaves much to be desired. It has a very unpolished feel. Novice administrators will probably find it difficult to use and understand. One of the first problems you might notice is that the menu (or table of contents) is unorganized. There is no logical order or grouping. The first items in the list provide low-level information primarily meant for developers. Currently, the order is determined by the initialization sequence in the source code.

The output is often ugly. The cachemgr.cgi program renders very bland-looking HTML pages. There are no icons or graphics of any kind. Furthermore, many of the pages are simply presented as unformatted text. cachemgr.cgi doesn't do much more than format tab-delimited lines as HTML tables and put tags around some URIs. Some of the cache manager pages are structured so that the output can be easily parsed by computer programs, rather than humans.

By today's standards, the cache manager has very weak security. You are essentially forced to use address-based controls and cleartext passwords. If you allow cache manager requests only from localhost, and your system security is good, you'll be relatively safe.

Squid-RRD

I personally use the cache manager to populate a number of RRDTool databases (http://www.rrdtool.com/). RRDTool is nice package for storing and displaying time-series data. It allows you to archive data at different time scales (e.g., days, weeks, months, years) in a database that doesn't grow in size over time.

I use a Perl script that runs every five minutes from cron. It issues cache manager requests for a number of pages and extracts the values that I am interested in. These values are stored in the RRD files.

RRDTool also generates nice-looking graphs, from either a CGI script or standalone program. I use the CGI program