systemd
Daemonjournalctl
: Query the systemd
Journaludev
Squid is a widely-used proxy cache for Linux and Unix platforms. This means that it stores requested Internet objects, such as data on a Web or FTP server, on a machine that is closer to the requesting workstation than the server. It can be set up in multiple hierarchies to assure optimal response times and low bandwidth usage, even in modes that are transparent to end users. Additional software like squidGuard can be used to filter Web content.
cachemgr.cgi
)Squid acts as a proxy cache. It redirects object requests from clients (in this case, from Web browsers) to the server. When the requested objects arrive from the server, it delivers the objects to the client and keeps a copy of them in the hard disk cache. An advantage of caching is that several clients requesting the same object can be served from the hard disk cache. This enables clients to receive the data much faster than from the Internet. This procedure also reduces the network traffic.
Along with actual caching, Squid offers a wide range of features:
Distributing load over intercommunicating hierarchies of proxy servers
Defining strict access control lists for all clients accessing the proxy
Allowing or denying access to specific Web pages using other applications
Generating statistics about frequently-visited Web pages for the assessment of surfing habits
Squid is not a generic proxy. It normally proxies only HTTP connections. It supports the protocols FTP, Gopher, SSL, and WAIS, but it does not support other Internet protocols, such as the news protocol, or video conferencing protocols. Because Squid only supports the UDP protocol to provide communication between different caches, many multimedia programs are not supported.
As a proxy cache, Squid can be used in several ways. When combined with a firewall, it can help with security. Multiple proxies can be used together. It can also determine what types of objects should be cached and for how long.
It is possible to use Squid together with a firewall to secure internal networks from the outside using a proxy cache. The firewall denies all clients access to external services except Squid. All Web connections must be established by the proxy. With this configuration, Squid completely controls Web access.
If the firewall configuration includes a DMZ, the proxy should operate within this zone. Section 26.5, “Configuring a Transparent Proxy” describes how to implement a transparent proxy. This simplifies the configuration of the clients, because in this case, they do not need any information about the proxy.
Several instances of Squid can be configured to exchange objects between them. This reduces the total system load and increases the chances of retrieving an object from the local network. It is also possible to configure cache hierarchies, so a cache can forward object requests to sibling caches or to a parent cache—causing it to request objects from another cache in the local network or directly from the source.
Choosing the appropriate topology for the cache hierarchy is very important, because it is not desirable to increase the overall traffic on the network. For a very large network, it would make sense to configure a proxy server for every subnet and connect them to a parent proxy, which in turn is connected to the proxy cache of the ISP.
All this communication is handled by ICP (Internet cache protocol) running on top of the UDP protocol. Data transfers between caches are handled using HTTP (hypertext transmission protocol) based on TCP.
To find the most appropriate server from which to request objects, a cache
sends an ICP request to all sibling proxies. The sibling proxies answer
these requests via ICP responses. If the object was detected, they use the
code HIT
, if not, they use MISS
.
If multiple HIT
responses were found, the proxy server
decides from which server to download, depending on factors such as which
cache sent the fastest answer or which one is closer. If no satisfactory
responses are received, the request is sent to the parent cache.
To avoid duplication of objects in different caches in the network, other ICP protocols are used, such as CARP (cache array routing protocol) or HTCP (hypertext cache protocol). The more objects maintained in the network, the greater the possibility of finding the desired one.
Many objects available in the network are not static, such as dynamically generated pages and TLS/SSL-encrypted content. Objects like these are not cached because they change each time they are accessed.
To determine how long objects should remain in the cache, objects are assigned one of several states. Web and proxy servers find out the status of an object by adding headers to these objects, such as “Last modified” or “Expires” and the corresponding date. Other headers specifying that objects must not be cached can be used as well.
Objects in the cache are normally replaced, because of a lack of free disk space, using algorithms such as LRU (last recently used). This means that the proxy expunges those objects that have not been requested for the longest time.
System requirements largely depend on the maximum network load that the system must bear. Therefore, examine load peaks, as during those times, load might be more than four times the day's average. When in doubt, slightly overestimate the system's requirements. Having Squid working close to the limit of its capabilities can lead to a severe loss in quality of service. The following sections point to system factors in order of significance:
RAM size
CPU speed/physical CPU cores
Size of the disk cache
Hard disks/SSDs and their architecture
The amount of memory (RAM) required by Squid directly correlates with the number of objects in the cache. Random access memory is much faster than a hard disk/SSD. Therefore, it is very important to have sufficient memory for the Squid process, because system performance is dramatically reduced if it must be swapped to disk.
Squid also stores cache object references and frequently requested objects in the main memory to speed up retrieval of this data. In addition to that, there is other data that Squid needs to keep in memory, such as a table with all the IP addresses handled, an exact domain name cache, the most frequently requested objects, access control lists, buffers, and more.
Squid is tuned to work best with lower processor core counts (4–8 physical cores), with each providing high performance. Technologies providing virtual cores such as hyperthreading can hurt performance.
To make the best use of multiple CPU cores, it is necessary to set up multiple worker threads writing to different caching devices. By default, multi-core support is mostly disabled.
In a small cache, the probability of a HIT
(finding the
requested object already located there) is small, because the cache is
easily filled and less requested objects are replaced by newer ones. If,
for example, 1 GB is available for the cache and the users use up only
10 MB per day surfing, it would take more than one hundred days to
fill the cache.
The easiest way to determine the necessary cache size is to consider the maximum transfer rate of the connection. With a 1 Mbit/s connection, the maximum transfer rate is 128 KB/s. If all this traffic ended up in the cache, in one hour it would add up to 460 MB. Assuming that all this traffic is generated in only eight working hours, it would reach 3.6 GB in one day. Because the connection is normally not used to its upper volume limit, it can be assumed that the total data volume handled by the cache is approximately 2 GB. Hence, in this example, 2 GB of disk space is required for Squid to keep one day's worth of browsing data cached.
Speed plays an important role in the caching process, so this factor deserves special attention. For hard disks/SSDs, this parameter is described as random seek time or random read performance, measured in milliseconds. Because the data blocks that Squid reads from or writes to the hard disk/SSD tend to be small, the seek time/read performance of the hard disk/SSD is more important than its data throughput.
For use as a proxy, hard disks with high rotation speeds or SSDs are the best choice. When using hard disks, it can be better to use multiple smaller hard disks, each with a single cache directory to avoid excessive read times.
Using a RAID system allows increasing reliability at expense of speed. However, for performance reasons, avoid (software) RAID5 and similar settings.
File system choice is usually not decisive. However, using the mount option
noatime
can improve performance—Squid provides its
own time stamps and thus does not need the file system to track access
times.
If not already installed, install the package
squid
. squid
is not among the packages installed by
default on openSUSE® Leap.
Squid is already preconfigured in openSUSE Leap, you can start it directly
after the installation. To ensure a smooth start-up, the network should be
configured in a way that at least one name server and the Internet can be
reached. Problems can arise if a dial-up connection is used with a dynamic
DNS configuration. In this case, at least the name server should be
specified, because Squid does not start if it does not detect a DNS server
in /etc/resolv.conf
.
To start Squid, use:
tux >
sudo systemctl start squid
If you want Squid to start together with the system, enable the service
with systemctl enable squid
.
To check whether Squid is running, choose one of the following ways:
Using systemctl
:
tux >
systemctl start squid
The output of this command should indicate that Squid is
loaded
and active (running)
.
Using Squid itself:
tux >
sudo squid -k | echo $?
The output of this command should be 0
, without
further messages.
To test the functionality of Squid on the local system, choose one of the following ways:
To test, you can use squidclient
, a command-line tool
that can output the response to a Web request, similar to
wget
or curl
.
Unlike those tools, squidclient
will automatically
connect to the default proxy setup of Squid,
localhost:3128
. However, if you changed the
configuration of Squid, you need to configure
squidclient
to use different settings using command
line options. For more information, see squidclient
--help
.
squidclient
#tux >
squidclient http://www.example.org
HTTP/1.1 200 OK Cache-Control: max-age=604800 Content-Type: text/html Date: Fri, 22 Jun 2016 12:00:00 GMT Expires: Fri, 29 Jun 2016 12:00:00 GMT Last-Modified: Fri, 09 Aug 2013 23:54:35 GMT Server: ECS (iad/182A) Vary: Accept-Encoding X-Cache: HIT x-ec-custom-error: 1 Content-Length: 1270 X-Cache: MISS from moon1 X-Cache-Lookup: MISS from moon:3128 Via: 1.1 moon (squid/3.5.16)2 Connection: close <!doctype html> <html> <head> <title>Example Domain</title> [...] </body> </html>
The output shown in Example 26.1, “A Request With squidclient
” can be
split into two parts:
The protocol headers of the response: the lines before the blank line.
The actual content of the response: the lines after the blank line.
To verify that Squid is used, refer to the selected header lines:
The value of the header
The example above contains two | |
The value of the header |
Using a browser: Set up localhost
as the proxy and
3128
as the port. You can then load a page and check the
response headers in the panel of the browser's
Inspector or Developer Tools.
The headers should be reproduced similarly to the way shown in
Example 26.1, “A Request With squidclient
”.
To allow users from the local system and other systems to access Squid and
the Internet, change the entry in the configuration files
/etc/squid/squid.conf
from http_access deny
all
to http_access allow all
. However, in doing
so, consider that Squid is made completely accessible to anyone by this
action. Therefore, define ACLs (access control lists) that control access
to the proxy. After modifying the configuration file, Squid must be
reloaded or restarted. For more information on ACLs, see
Section 26.4.2, “Options for Access Controls”.
If Squid dies after a short period of time even though it was started
successfully, check whether there is a faulty name server entry or whether
the /etc/resolv.conf
file is missing. Squid logs the
cause of a start-up failure in the file
/var/log/squid/cache.log
.
Do this with systemctl reload squid
. Alternatively,
completely restart Squid with systemctl restart squid
.
The command systemctl stop squid
causes Squid to shut
down. This can take a while, because Squid waits up to half a minute
(shutdown_lifetime
option in
/etc/squid/squid.conf
) before dropping the connections
to the clients and writing its data to the disk.
Removing Squid from the system does not remove the cache hierarchy and log
files. To remove these, delete the /var/cache/squid
directory manually.
Setting up a local DNS server makes sense even if it does not manage its own domain. It then simply acts as a caching-only name server and is also able to resolve DNS requests via the root name servers without requiring any special configuration (see Section 19.4, “Starting the BIND Name Server”). How this can be done depends on whether you chose dynamic DNS during the configuration of the Internet connection.
Normally, with dynamic DNS, the DNS server is set by the provider during
the establishment of the Internet connection and the local
/etc/resolv.conf
file is adjusted automatically.
This behavior is controlled in the
/etc/sysconfig/network/config
file with the
NETCONFIG_DNS_POLICY
sysconfig variable. Set
NETCONFIG_DNS_POLICY
to ""
with the YaST sysconfig editor.
Then, add the local DNS server in the
/etc/resolv.conf
file with the IP address
127.0.0.1
for
localhost
. This way, Squid
can always find the local name server when it starts.
To make the provider's name server accessible, specify it in the
configuration file /etc/named.conf
under
forwarders
along with its IP address. With
dynamic DNS, this can be achieved automatically when establishing the
connection by setting the sysconfig variable
NETCONFIG_DNS_POLICY
to auto
.
With static DNS, no automatic DNS adjustments take place while
establishing a connection, so there is no need to change any sysconfig
variables. However, you must specify the local DNS server in the file
/etc/resolv.conf
as described in
Dynamic DNS. Additionally, the provider's
static name server must be specified manually in the
/etc/named.conf
file under
forwarders
along with its IP address.
If you have a firewall running, make sure DNS requests can pass it.
All Squid proxy server settings are made in the
/etc/squid/squid.conf
file. To start Squid for the
first time, no changes are necessary in this file, but external clients are
initially denied access. The proxy is available for
localhost
. The default port
is 3128
. The preinstalled configuration file
/etc/squid/squid.conf
provides detailed information
about the options and many examples.
Many entries are commented and therefore begin with the comment character
#
. The relevant specifications can be found at the end of
the line.
The given values usually correlate with the default values, so removing the
comment signs without changing any of the parameters usually has no effect.
If possible, leave the commented lines as they are and insert the options
along with the modified values in the line below. This way, the default
values may easily be recovered and compared with the changes.
If you have updated from an earlier Squid version, it is recommended to
edit the new /etc/squid/squid.conf
and only apply the
changes made in the previous file.
Sometimes, Squid options are added, removed, or modified. Therefore, if you
try to use the old squid.conf
, Squid might stop
working properly.
The following is a list of a selection of configuration options for
Squid. It is not exhaustive. The Squid package contains a full, lightly
documented list of options in
/etc/squid/squid.conf.documented
.
http_port PORT
This is the port on which Squid listens for client requests. The default
port is 3128
, but 8080
is also common.
cache_peer HOST_NAME
TYPE PROXY_PORT ICP_PORT
This option allows creating a network of caches that work together. The
cache peer is a computer that also hosts a network cache and stands in a
relationship to your own. The type of relationship is specified as the
TYPE. The type can either be
parent
or sibling
.
As the HOST_NAME, specify the name or IP
address of the proxy to use. For PROXY_PORT,
specify the port number for use in a browser (usually
8080
). Set ICP_PORT to
7
or, if the ICP port of the parent is not known and
its use is irrelevant to the provider, to 0
.
To make Squid behave like a Web browser instead of like a proxy,
prohibit the use of the ICP protocol. You can do so by appending the
options default
and no-query
.
cache_mem SIZE
This option defines the amount of memory Squid can use for very popular
replies. The default is 8 MB
. This does not specify the
memory usage of Squid and may be exceeded.
cache_dir
STORAGE_TYPE CACHE_DIRECTORY
CACHE_SIZE
LEVEL_1_DIRECTORIES
LEVEL_2_DIRECTORIES
The option cache_dir
defines the directory for the
disk cache. In the default configuration on openSUSE Leap, Squid does
not create a disk cache.
The placeholder STORAGE_TYPE can be one of the following:
Directory-based storage types: ufs
,
aufs
(the default), diskd
. All
three are variations of the storage format ufs
.
However, while ufs
runs as part of the core Squid
thread, aufs
runs in a separate thread, and
diskd
uses a separate process. This means that the
latter two types avoid blocking Squid because of disk I/O.
Database-based storage systems: rock
. This storage
format relies on a single database file, in which each object takes up
one or more memory units of a fixed size (“slots”).
In the following, only the parameters for storage types based on
ufs
will be discussed. rock
has
somewhat different parameters.
The CACHE_DIRECTORY is the directory for the
disk cache. By default, that is /var/cache/squid
.
CACHE_SIZE is the maximum size of that
directory in megabytes; by default, this is set to 100 MB. Set it
to between 50% and a maximum of 80% of available disk space.
The final two values, LEVEL_1_DIRECTORIES and LEVEL_2_DIRECTORIES specify how many subdirectories are created in the CACHE_DIRECTORY. By default, 16 subdirectories are created at the first level below CACHE_DIRECTORY and 256 within each of these. These values should only be increased with caution, because creating too many directories can lead to performance problems.
If you have several disks that share a cache, specify several
cache_dir
lines.
cache_access_log LOG_FILE
, cache_log LOG_FILE
, cache_store_log LOG_FILE
These three options specify the paths where Squid logs all its actions. Normally, nothing needs to be changed here. If Squid is burdened by heavy usage, it might make sense to distribute the cache and the log files over several disks.
client_netmask NETMASK
This option allows masking IP addresses of clients in the log files by
applying a subnet mask. For example, to set the last digit of the IP
address to 0
, specify
255.255.255.0
.
ftp_user E-MAIL
This option allows setting the password that Squid should use for anonymous FTP login. Specify a valid e-mail address here, because some FTP servers check these for validity.
cache_mgr E-MAIL
If it unexpectedly crashes, Squid sends a message to this e-mail address. The default is webmaster.
logfile_rotate VALUE
If you run squid
-k rotate
,
Squid
can rotate log files. The files are numbered in
this process and, after reaching the specified value, the oldest file is
overwritten. The default value is 10
which rotates log
files with the numbers 0 to 9.
However, on openSUSE Leap, rotating log files is performed automatically
using logrotate
and the
configuration file /etc/logrotate.d/squid
.
append_domain DOMAIN
Use append_domain to specify which domain to append automatically when none is given. Usually, your own domain is specified here, so specifying www in the browser accesses your own Web server.
forwarded_for STATE
If this option is set to on
, it adds a line to the
header similar to this:
X-Forwarded-For: 192.168.0.1
If you set this option to off
, Squid removes the IP
address and the system name of the client from HTTP requests.
negative_ttl TIME
, negative_dns_ttl TIME
If these options are set, Squid will cache some types of failures, such
as 404
responses. It will then refuse to issue new
requests, even if the resource would be available then.
By default, negative_ttl
is set to
0
, negative_dns_ttl
is set to
1 minutes
.
This means that negative responses to Web requests are not cached by
default, while negative responses to DNS requests are cached for 1
minute.
never_direct allow ACL_NAME
To prevent Squid from taking requests directly from the Internet, use
the option never_direct
to force connection to
another proxy. This must have previously been specified in
cache_peer
. If all
is specified as
the ACL_NAME, all requests are forwarded
directly to the parent
. This can be necessary, for
example, if you are using a provider that dictates the use of its
proxies or denies its firewall direct Internet access.
Squid provides a detailed system for controlling the access to the proxy.
These Access Control Lists (ACL) are lists with rules that are processed
sequentially. ACLs must be defined before they can be used. Some default
ACLs, such as all
and localhost
,
already exist. However, the mere definition of an ACL does not mean that it
is actually applied. This only happens when there is a corresponding
http_access
rule.
The syntax for the option acl
is as follows:
acl ACL_NAME TYPE DATA
The placeholders within this syntax stand for the following:
The name ACL_NAME can be chosen arbitrarily.
For TYPE, select from a variety of different
options which can be found in the ACCESS CONTROLS
section in the /etc/squid/squid.conf
file.
The specification for DATA depends on the individual ACL type and can also be read from a file. For example, “via” host names, IP addresses, or URLs.
For more information on types of ACL rules, see the Squid documentation at http://www.squid-cache.org/Versions/v3/3.5/cfgman/acl.html.
acl mysurfers srcdomain .example.com 1 acl teachers src 192.168.1.0/255.255.255.0 2 acl students src 192.168.7.0-192.168.9.0/255.255.255.0 3 acl lunch time MTWHF 12:00-15:00 4
This ACL defines | |
This ACL defines | |
This ACL defines | |
This ACL defines |
http_access
defines who is allowed to use the proxy and
who can access what on the Internet. For this, ACLs must be defined.
localhost
and all
have already
been defined above for which you can deny or allow access via
deny
or allow
. A list containing
any number of http_access
entries can be created,
processed from top to bottom. Depending on which occurs first, access is
allowed or denied to the respective URL. The last entry should always be
http_access deny all
. In the following example,
localhost
has free access to everything while all
other hosts are denied access completely:
http_access allow localhost http_access deny all
In another example using these rules, the group
teachers
always has access to
the Internet. The group
students
only has access
between Monday and Friday during lunch time:
http_access deny localhost http_access allow teachers http_access allow students lunch time http_access deny all
For readability, within the configuration file
/etc/squid/squid.conf
, specify all
http_access
options as a block.
url_rewrite_program PATH
With this option, specify a URL rewriter. For example, this can be
squidGuard (/usr/sbin/squidGuard
) which allows
blocking unwanted URLs. With it, Internet access can be individually
controlled for various user groups using proxy authentication and the
appropriate ACLs.
For more information on squidGuard, see Section 26.7, “squidGuard”.
auth_param basic program
PATH
If users must be authenticated on the proxy, set a corresponding
program, such as /usr/sbin/pam_auth
. When accessing
pam_auth
for the first time, the user sees a login
window in which they need to specify a user name and a password. In
addition, you need an ACL, so only clients with a valid login can use
the Internet:
acl password proxy_auth REQUIRED http_access allow password http_access deny all
In the acl proxy_auth
option, using
REQUIRED
means that all valid user names are
accepted. REQUIRED
can also be replaced with a list
of permitted user names.
ident_lookup_access allow
ACL_NAME
With this option, have an ident request run to find each user's identity
for all clients defined by an ACL of the type src
.
Alternatively, use this for all clients, apply the predefined ACL
all
as the ACL_NAME.
All clients covered by ident_lookup_access
must run an
ident daemon. On Linux, you can use
pidentd
(package
pidentd
) as the ident daemon. For other operating systems, free software is
usually available. To ensure that only clients with a successful ident
lookup are permitted, define a corresponding ACL:
acl identhosts ident REQUIRED http_access allow identhosts http_access deny all
In the acl identhosts ident
option, using
REQUIRED
means that all valid user names are
accepted. REQUIRED
can also be replaced with a list
of permitted user names.
Using ident
can slow down access time, because ident
lookups are repeated for each request.
The usual way of working with proxy servers is the following: the Web browser sends requests to a certain port of the proxy server and the proxy always provides these required objects, regardless of whether they are in its cache. However, in some cases the transparent proxy mode of Squid makes sense:
If, for security reasons, it is recommended that all clients use a proxy to surf the Internet.
If all clients must use a proxy, regardless of whether they are aware of it.
If the proxy in a network is moved, but the existing clients need to retain their old configuration.
A transparent proxy intercepts and answers the requests of the Web browser, so the Web browser receives the requested pages without knowing where they are coming from. As the name indicates, the entire process is transparent to the user.
In /etc/squid/squid.conf
, on the line of the option
http_port
add the parameter
transparent
:
http_port 3128 transparent
Restart Squid:
tux >
sudo systemctl restart squid
Set up SuSEFirewall2 to redirect HTTP traffic to the port given in
http_proxy
(in the example above, that was port 3128). To
do so, edit the configuration file
/etc/sysconfig/SuSEfirewall2
.
This example assumes that you are using the following devices:
Device pointing to the Internet: FW_DEV_EXT="eth1"
Device pointing to the network: FW_DEV_INT="eth0"
Define ports and services (see /etc/services
) on the
firewall that are accessed from untrusted (external) networks such as the
Internet. In this example, only Web services are offered to the outside:
FW_SERVICES_EXT_TCP="www"
Define ports or services (see /etc/services
) on the
firewall that are accessed from the secure (internal) network, both via
TCP and UDP:
FW_SERVICES_INT_TCP="domain www 3128" FW_SERVICES_INT_UDP="domain"
This allows accessing Web services and Squid (whose default port is
3128
). The service “domain” stands for DNS
(domain name service). This service is commonly used. Otherwise, simply
remove domain
from the above entries and set the
following option to no
:
FW_SERVICE_DNS="yes"
The option FW_REDIRECT
is very important, as it is used
for the actual redirection of HTTP traffic to a specific port. The
configuration file explains the syntax in a comment above the option:
# Format: # list of <source network>[,<destination network>,<protocol>[,dport[:lport]] # Where protocol is either tcp or udp. dport is the original # destination port and lport the port on the local machine to # redirect the traffic to # # An exclamation mark in front of source or destination network # means everything EXCEPT the specified network
That is:
Specify the IP address and the netmask of the internal networks accessing the proxy firewall.
Specify the IP address and the netmask to which these clients send their
requests. In the case of Web browsers, specify the networks
0/0
, a wild card that means “to
everywhere.”
Specify the original port to which these requests are sent.
Specify the port to which all these requests are redirected. In the
example below, only Web services (port 80
) are
redirected to the proxy port (port 3128
). If there
are more networks or services to add, separate them with a space in the
respective entry.
Because Squid supports protocols other than HTTP, you can also redirect requests from other ports to the proxy. For example, you can also redirect port 21 (FTP) and port 443 (HTTPS or SSL).
Therefore, for a Squid configuration, you could use:
FW_REDIRECT="192.168.0.0/16,0/0,tcp,80,3128"
In the configuration file
/etc/sysconfig/SuSEfirewall2
, make sure that
the entry START_FW
is set to "yes"
.
Restart SuSEFirewall2:
tux >
sudo systemctl restart SuSEfirewall2
To verify that everything is working properly, check the Squid log files
in /var/log/squid/access.log
. To verify that all
ports are correctly configured, perform a port scan on the machine from
any computer outside your network. Only the Web services (port 80) should
be open. To scan the ports with nmap
, use:
nmap
-O IP_ADDRESS
cachemgr.cgi
) #
The Squid cache manager CGI interface (cachemgr.cgi
) is
a CGI utility for displaying statistics about the memory usage of a running
Squid process. It is also a convenient way to manage the cache and view
statistics without logging the server.
cachemgr.cgi
#Make sure the Apache Web server is running on your system. Configure Apache as described in Chapter 24, The Apache HTTP Server. In particular, see Section 24.5, “Enabling CGI Scripts”. To check whether Apache is already running, use:
tux >
sudo systemctl status apache2
If inactive
is shown, you can start Apache with the
openSUSE Leap default settings:
tux >
sudo systemctl start apache2
Now enable cachemgr.cgi
in
Apache. To do so, create a configuration file for a
ScriptAlias
.
Create the file in the directory /etc/apache2/conf.d
and name it cachemgr.conf
. In it, add the following:
ScriptAlias /squid/cgi-bin/ /usr/lib64/squid/ <Directory "/usr/lib64/squid/"> Options +ExecCGI AddHandler cgi-script .cgi Require host HOST_NAME </Directory>
Replace HOST_NAME with the host name of the
computer you want to access
cachemgr.cgi
from. This allows
only your computer to access
cachemgr.cgi
. To allow access
from anywhere, use Require all granted
instead.
If Squid and your Apache Web server run on the same computer, there
should be no changes that need to be made to
/etc/squid/squid.conf
. However, verify that
/etc/squid/squid.conf
contains the following lines:
http_access allow manager localhost http_access deny manager
These lines allow you to access the manager interface from your own
computer (localhost
) but not from elsewhere.
If Squid and your Apache Web server run on different computers, you need to add extra rules to allow access from the CGI script to Squid. Define an ACL for your server (replace WEB_SERVER_IP with the IP address of your Web server):
acl webserver src WEB_SERVER_IP/255.255.255.255
Make sure the following rules are in the configuration file. Compared to the default configuration, only the rule in the middle is new. However, the sequence is important.
http_access allow manager localhost http_access allow manager webserver http_access deny manager
(Optional)
Optionally, you can configure one or more passwords for
cachemgr.cgi
. This also allows
access to more actions such as closing the cache remotely or viewing more
information about the cache. For this, configure the options
cache_mgr
and cachemgr_passwd
with one
or more password for the manager and a list of allowed actions.
For example, to explicitly enable viewing the index page, the menu,
60-minute average of counters without authentication, to enable toggling
offline mode using the password secretpassword
, and to
completely disable everything else, use the following configuration:
cache_mgr user cachemgr_passwd none index menu 60min cachemgr_passwd secretpassword offline_toggle cachemgr_passwd disable all
cache_mgr
defines a user name. cache_mgr
defines which actions are allowed using which password.
The keywords none
and disable
are
special: none
removes the need for a password,
disable
disables functionality outright.
The full list of actions can be best seen after logging in to
cachemgr.cgi
. To find out how
the operation needs to be referenced in the configuration file, see the
string after &operation=
in the URL of the action
page. all
is a special keyword meaning all actions.
Reload Squid and Apache after the configuration file changes:
tux >
sudo systemctl reload squid
To view the statistics, go to the
cachemgr.cgi
page that you set
up before. For example, it could be
http://webserver.example.org/squid/cgi-bin/cachemgr.cgi
.
Choose the right server, and, if set, specify user name and password. Then click
and browse through the different statistics.This section is not intended to explain an extensive configuration of squidGuard, only to introduce it and give some advice for using it. For more in-depth configuration issues, refer to the squidGuard Web site at http://www.squidguard.org.
squidGuard is a free (GPL), flexible, and fast filter, redirector, and access controller plug-in for Squid. It lets you define multiple access rules with different restrictions for different user groups on a Squid cache. squidGuard uses Squid's standard redirector interface. squidGuard can do the following:
Limit Web access for some users to a list of accepted or well-known Web servers or URLs.
Block access to some listed or blacklisted Web servers or URLs for some users.
Block access to URLs matching a list of regular expressions or words for some users.
Redirect blocked URLs to an “intelligent” CGI-based information page.
Redirect unregistered users to a registration form.
Redirect banners to an empty GIF.
Use different access rules based on time of day, day of the week, date, etc.
Use different rules for different user groups.
squidGuard and Squid cannot be used to:
Edit, filter, or censor text inside documents.
Edit, filter, or censor HTML-embedded scripts such as JavaScript.
Before it can be used, install squidGuard .
Provide a minimal configuration file as
/etc/squidguard.conf
. Find configuration examples in
http://www.squidguard.org/Doc/examples.html.
Experiment later with more complicated configuration settings.
Next, create an “access denied” HTML page or CGI page that Squid can redirect to if the client requests a blacklisted Web site. Using Apache is strongly recommended.
Now, configure Squid to use squidGuard. Use the following entry in the
/etc/squid/squid.conf
file:
redirect_program /usr/bin/squidGuard
Another option called redirect_children
configures the number of “redirect” (in this case squidGuard)
processes running on the machine. The more processes you set, the more RAM
is required. Try low numbers first, for example, 4
:
redirect_children 4
Last, have Squid load the new configuration by running systemctl
reload squid
. Now, test your settings with a browser.
Calamaris is a Perl script used to generate reports of cache activity in
ASCII or HTML format. It works with native Squid access log files. The
Calamaris home page is located at
http://cord.de/calamaris-english. This tool does not
belong to the openSUSE Leap default installation scope—to use it,
install the calamaris
package.
Log in as root
, then enter:
cat access1.log [access2.log access3.log] | calamaris options > reportfile
When using more than one log file, make sure they are chronologically
ordered, with older files listed first. This can be achieved by either
listing the files one after the other as in the example above, or by using
access{1..3}.log
.
calamaris
takes the following options:
-a
output all available reports
-w
output as HTML report
-l
include a message or logo in report header
More information about the various options can be found in the program's
manual page with man
calamaris
.
A typical example is:
cat access.log.{10..1} access.log | calamaris -a -w \ > /usr/local/httpd/htdocs/Squid/squidreport.html
This puts the report in the directory of the Web server. Apache is required to view the reports.
Visit the home page of Squid at http://www.squid-cache.org/. Here, find the “Squid User Guide” and a very extensive collection of FAQs on Squid.
In addition, mailing lists are available for Squid at http://www.squid-cache.org/Support/mailing-lists.html.