On 21/06/2012 5:43 p.m., Anonymous wrote:
Thank you very much for detailed information with examples.
I have setup ACL as given below:
# ---------Start Here ------------------------
acl OpenIPs src "/etc/squid3/AlwaysOpenIPs.txt"
acl TimedTubed src "/etc/squid3/TimeBasedIPs.txt"
acl NoTubeTime time SMTWHFA 09:00-14:59
acl deny_rep_mime_flashvideo rep_mime_type video/x-flv
http_reply_access allow OpenIPs
http_reply_access allow TimedTubed NoTubeTime
http_reply_access deny deny_rep_mime_flashvideo
http_reply_access allow all
# ---------End Here ------------------------
Now "TimedTubed" (Time based youtube/video streaming access) can access all other web sites BUT after the restricted time (09:00-14:59) @ 15:00, they can not access the you tube website.
I want to allow the "TimedTubed" IPs to access you tube only from 15:00 till 08:59.
Then you reverse the allowed timespan:
http_reply_access allow TimedTubed !NoTubeTime
OR,
specify "between 5pm and 9am". But since the clock wraps around 00:00
you need to write it as two ranges.
acl NoTubeTime time 00:00-08:59
acl NoTubeTime time 15:00-23:59
Amos
Thank you very much for your time and kind help.
Regards.
-------------------------------------------------------------
--- On Thu, 6/21/12, Amos Jeffries <squid3@xxxxxxxxxxxxx> wrote:
From: Amos Jeffries <squid3@xxxxxxxxxxxxx>
Subject: Re: Time based Video Streaming Access
To: "Anonymous" <eletters_mail@xxxxxxxxx>
Cc: squid-users@xxxxxxxxxxxxxxx
Date: Thursday, June 21, 2012, 4:27 AM
On 20.06.2012 20:31, Anonymous
wrote:
Dear Amos Jeffries and All,
Thank you very much for great help. I am trying to
understand the
actual working of "http_reply_access [allow|deny]" and
"http_access
[allow|deny]". Can you please tell me the format,
especailly the
"ORDER" of ACL Statements, as "http_reply_access
[allow|deny]" and
"http_access [allow|deny]" are bit tricky and I am
confused howto set
the order of acl statements.
http_access lines are tested as soon as the HTTP request is
received. Using only the TCP connection and HTTP request
details (no HTTP reply details). To decide whether Squid is
going to reject the request or try to handle it.
http_reply_access is tested as soon the HTTP reply is
received. Using TCP connection details, HTTP request and
reply details. To decide whether Squid is going to deliver
the response or send an error instead.
There is no configuration relevant in ordering of between
http_access and http_reply_access lines. Each one will be
separated in to a sequence of its own type of line.
eg
http_access allow A
http_reply_access deny B
http_access allow C
is the same as:
http_access allow A
http_access allow C
http_reply_access deny B
"acl" directive lines are just definitions of how to run a
particular test. The only ordering they have is to be listed
in the config before they are used on any other directive
lines.
Lines for each access directive type (eg, http_access) are
processed top-to-bottom first matching whole line does its
action. Individual ACL on each line are tested left-to-right
with first mis-matching ACL stopping that lines test.
For example:
http_access allow A B C
http_access deny D E
means:
if A *and* B *and* C tests all match, ALLOW the
request
OR,
if D *and* E tests all match, DENY the request
OR
do the opposite of DENY
With some logic performance tricks like:
If B does not match the whole first line will not
match so C will not be tested. (one less test == faster
handling time).
More details can be found at http://wiki.squid-cache.org/SquidFaq/SquidAcl
HTH
Amos
Thank you very much for your time and help.
--- On Wed, 6/20/12, Amos Jeffries <squid3@xxxxxxxxxxxxx>
wrote:
From: Amos Jeffries <squid3@xxxxxxxxxxxxx>
Subject: Re: Time based Video
Streaming Access
To: squid-users@xxxxxxxxxxxxxxx
Date: Wednesday, June 20, 2012, 7:23 AM
On 19.06.2012 23:57, Anonymous
wrote:
Hello Respected All,
I want to setup Time based Video Streaming
Access for
different IPs
(same subnet), few IPs are allowed every time
video/you
tube streaming
access, while other IPs (IPs list in file as
SRC) are
only allowed in
set time duration any other IPs are not
allowed to
access Video/You
tube access. Here's setup:
-------------------
Ubuntu 12.04
Squid 3.1.x
Two Groups of IPs
G-1 = Allowd Everytime
G-2 = Time Restriction (09:00-14:59)
G-3 = Everybody, Deny Access to Video/You
tube
streaming every time.
------------------------------
acl OpenIPs src "/etc/squid3/AlwaysOpenIPs.
txt" # G-1=
List of IPs
allowed for Video Streaming Everytime.
acl TimedTubed src
"/etc/squid3/TimeBasedIPs.txt" # G-2
= List of IPs
allowed for set time duration.
acl NoTubeTime time SMTWHFA 08:30-14:59 # Time
duration
when you
access to Time based IPs.
acl deny_rep_mime_flashvideo rep_mime_type
video/x-flv
# ACL to Deny
Video Straming for everyone else.
http_reply_access allow OpenIPs TimedTubed
NoTubeTime
This above line can only allow the IPs which are
listed in
*both* OpenIPs and TimedTubed.
It will allow them only during NoTubeTime.
If I'm reading your policy description above
correctly you
actually want:
# G-1 policy = Allowed Everytime
http_reply_access allow OpenIPs
# G-2 policy = Time Restriction (09:00-14:59)
http_reply_access allow TimedTubed NoTubeTime
http_reply_access deny TimedTubed
That above line seems wrong according to your
stated
policies. It will block TimedTubed IPs from going
to
non-YouTube content.
# G-3 policy = Deny Access to Video/You tube
streaming every time.
http_reply_access deny
deny_rep_mime_flashvideo
http_reply_access allow all
------------------------------
-----------------------
Above mentioned ACLs are not working properly,
General
Internet
Access (http_access) is also denied when used
with
"http_reply_access
deny" I want to only deny video streaming/you
tube in
set time
duration and allow internet access.
Thank you in advance.
One thing to note here. Blocking in
http_reply_access means
the video is already arriving when you decide not
to deliver
it. squid id forced to do one of two things:
a) close the server connection and wait out
the TCP reset
timouts (15 minutes) before re-using the socket.
Not a major
issue on networks with low web traffic, but can be
a major
problem if you are needing to use those sockets
again fast.
b) read in the entire video from the server
and discard it
before re-using the socket. Avoids TCP timeouts,
but
provides wastes bandwidth and may on some videos
take longer
than a 15-min TCP reset would have.
NOTE: You also need to consider an http_access or
miss_access ACL block to prevent people not allowed
to view
videos from even making a request to the video site
in the
first place. This front-line block is where the
bandwidth
and speed savings will come from. The
http_reply_access can
be used as an inefficient but more accurate block
only for
those requests which get past your front-line
blocking.
Amos
