<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<div class="moz-cite-prefix">W dniu 19.05.2017 o 17:16, Amos
Jeffries pisze:<br>
</div>
<blockquote type="cite"
cite="mid:15bde1d1-275f-9ec4-493f-06dd0db6aeae@treenet.co.nz">On
20/05/17 02:55, Dijxie wrote:
<br>
<blockquote type="cite">W dniu 19.05.2017 o 15:13, Amos Jeffries
pisze:
<br>
<blockquote type="cite">On 20/05/17 00:44, Dijxie wrote:
<br>
<blockquote type="cite">
<br>
Hi list,
<br>
<br>
1. I'd like to redirect **all** squid error pages to one,
universal, preferably internal squid error page. For sure I
can symlink every error page to one, but is there a clener
way?
<br>
I'm not sure if I get it:
<a class="moz-txt-link-freetext" href="http://www.squid-cache.org/Doc/config/deny_info/">http://www.squid-cache.org/Doc/config/deny_info/</a>
<br>
<br>
</blockquote>
<br>
deny_info is to provide some non-default response payload
(aka. "page") instead of the 403 when an ACL performs
administrative denial of access.
<br>
<br>
As to your purpose; What is this universal message that
conveys all possible environmental conditions to the reader in
one simple text?
<br>
<br>
Keep in mind that the reader may not be human; some errors are
explanations of indirect problems and only visible when the
accompanying machine instructions reach a failure (eg 30x,
401, 407 messages); and some are not errors at all but
instructions for a user on what they need to do to continue
with communication (eg 511 login pages).
<br>
<br>
<blockquote type="cite">2. And then, using %e code and
presumably external js nested in this page, display more
detailed info for some error numbers.
<br>
<br>
Can it be done? Can squid internal web server handle easy
js?
<br>
<br>
</blockquote>
<br>
Squid is not a web server. On "error" it produces message
payloads which happen to contain HTML by default. Modern HTML
can contain embedded scripts, but they are not interpreted by
Squid as anything beyond opaque characters.
<br>
<br>
<br>
If you redirect all errors to one URL any information the
client might have had about the error is destroyed.
<br>
<br>
The symlinking you though of is the "best" way to do what you
are asking for. However, think carefully about what the
purpose of displaying an error message is, see above.
<br>
<br>
Amos
<br>
<br>
_______________________________________________
<br>
squid-users mailing list
<br>
<a class="moz-txt-link-abbreviated" href="mailto:squid-users@lists.squid-cache.org">squid-users@lists.squid-cache.org</a>
<br>
<a class="moz-txt-link-freetext" href="http://lists.squid-cache.org/listinfo/squid-users">http://lists.squid-cache.org/listinfo/squid-users</a>
<br>
</blockquote>
<br>
The purpose is to provide unified, debug info for 1st line of
support. End users in my corpo are not best IT trained people in
the world and they tend to open tickets for any reason, usually
pasting printscreen into ticket.
<br>
Simple debug info like: IP, user name, client name, cache name
in short list would help service desk to divide "moronic"
tickets from important ones, and as for default squid info
pages... user do not read them anyway. I do not want to remove
error codes, I just want to remove content of most error pages
and replace it with unified message that also contains raw error
code (%e, %E) and add some more information if %e will be
nxdomain or access denied for example.
<br>
Unfortunately, I'm far from VPN right now, so I cannot show you
the sample "unified" error page I've commited till now.
<br>
<br>
But indeed, you have striked the home; cache users are both
human and machine$ AD accounts, I must reconsider that. Perhaps
parsing all error pages with sed ie and adding few lines will be
easer and more convenient, anyway.
<br>
I know that squid is not web serwer, but error page is html; I
assume it can contains iframe served from external web server
and this will be rendered by client's browser, not squid? My
idea was:
<br>
- js nested in squid error page looks for error code
<br>
- then redirects nested iframe to specific URL hosted on
external httpd depending on error code. If error code is
unimportant for human (user can do nothing with that anyway),
iframe stays blank.
<br>
- human client has has his explenation like "this is your error,
do not open ticket please, check your URL again" for nxdomain.
<br>
<br>
We are talking about ~2K users and 3-4 cache servers. I must
take comfort of first line support into concideration, they are
quite heavy-loaded already.
<br>
I'm not feeling comfortable with this idea, but I also have a
feeling that it might be necessity.
<br>
<br>
</blockquote>
<br>
I think a better approach may be a link they can click on that
automatically reports the details for them. Some of our errors
already include a mailto web link to contact the administrator
that embeds the error details in subject etc as an example. But
you can go a bit further with a jQuery script that pulls IP etc
and POSTs them to a support database API.
<br>
<br>
You can also reduce a bit of the work editing files by pointing
error_directory in squid.conf to a directory with your altered
templates. That will save your changes from being overwritten when
the OS packaged ones update.
<br>
<br>
Amos
<br>
<br>
_______________________________________________
<br>
squid-users mailing list
<br>
<a class="moz-txt-link-abbreviated" href="mailto:squid-users@lists.squid-cache.org">squid-users@lists.squid-cache.org</a>
<br>
<a class="moz-txt-link-freetext" href="http://lists.squid-cache.org/listinfo/squid-users">http://lists.squid-cache.org/listinfo/squid-users</a>
<br>
</blockquote>
<p><font size="-1">It would be yet another explanatory link they
don't ever click, unfortunately. But yes, I know it would be a
better approach. This is an organizational and 'political' issue
and me myself can do nothing about it.<br>
malto: is alredy removed - they cannot open tickets this way and
we do not want to be flooded by emails like that. <br>
</font></p>
<p><font size="-1">That was my pimal idea: simle database/array that
contains some criteria like:<br>
if %e is bad gateway and %I=10.10.10.69 and %i=10.22.0.0/16 then
iframe says: "we alredy told you 10000 times that you shall not
try to access %H server from %i network". Then I could give user
info database's managment to the people in service desk so they
can change info depending on the buisiness circumstances -
without reconfiguration of all squids (that should be identical
because of LB and FO) and harrasing my department of course :)<br>
</font></p>
<p><font size="-1">If they (end users) open a ticket in
circumstances they were precisely instructed not to do so, they
(their company) are extra charged. If they open a ticket because
they do not know what to do, service desk folks have to do
unnecessary work for nothing. And common practice is everybody
forgets to inform users and service desk about changes or 3rd
party supporting companies change something on their machines
causing huge mess and 2300 identical tickets within an hour; I'm
just trying to provide kind of dynamic, easy managed and functional
error page that can provide basic explenation for end users if
needed.<br>
</font></p>
<p><font size="-1">So: js/jq + external iframe in error page(s) is
something that does not violate standards? Let's not talk about
common sense here ;)<br>
</font></p>
<pre class="moz-signature" cols="72">Greets, Dijx</pre>
</body>
</html>