[squid-users] How to redirect all squid's error pages to one?

[Amos Jeffries]

On 20/05/17 04:22, Dijxie wrote:
> W dniu 19.05.2017 o 17:16, Amos Jeffries pisze:
>> On 20/05/17 02:55, Dijxie wrote:
>>> W dniu 19.05.2017 o 15:13, Amos Jeffries pisze:
>>>> On 20/05/17 00:44, Dijxie wrote:
>>>>>
>>>>> Hi list,
>>>>>
>>>>> 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?
>>>>> I'm not sure if I get it: 
>>>>> http://www.squid-cache.org/Doc/config/deny_info/
>>>>>
>>>>
>>>> deny_info is to provide some non-default response payload (aka. 
>>>> "page") instead of the 403 when an ACL performs administrative 
>>>> denial of access.
>>>>
>>>> As to your purpose; What is this universal message that conveys all 
>>>> possible environmental conditions to the reader in one simple text?
>>>>
>>>> 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).
>>>>
>>>>> 2. And then, using %e code and presumably external js nested in 
>>>>> this page, display more detailed info for some error numbers.
>>>>>
>>>>> Can it be done? Can squid internal web server handle easy js?
>>>>>
>>>>
>>>> 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.
>>>>
>>>>
>>>> If you redirect all errors to one URL any information the client 
>>>> might have had about the error is destroyed.
>>>>
>>>> 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.
>>>>
>>>> Amos
>>>>
>>>> _______________________________________________
>>>> squid-users mailing list
>>>> squid-users at lists.squid-cache.org
>>>> http://lists.squid-cache.org/listinfo/squid-users
>>>
>>> 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.
>>> 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.
>>> Unfortunately, I'm far from VPN right now, so I cannot show you the 
>>> sample "unified" error page I've commited till now.
>>>
>>> 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.
>>> 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:
>>> - js nested in squid error page looks for error code
>>> - 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.
>>> - human client has has his explenation like "this is your error, do 
>>> not open ticket please, check your URL again" for nxdomain.
>>>
>>> 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.
>>> I'm not feeling comfortable with this idea, but I also have a 
>>> feeling that it might be necessity.
>>>
>>
>> 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.
>>
>> 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.
>>
> 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.
>

For some maybe, if it is a major problem then make it an auto-fetch 
jQuery instead so they dont need to click at all, the report "just 
happens". That will also filter a lot of the machine-specific occurances 
out.

> malto: is alredy removed - they cannot open tickets this way and we do 
> not want to be flooded by emails like that.
>
> That was my pimal idea: simle database/array that contains some 
> criteria like:
> 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 :)
>
> 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.
>
> So: js/jq + external iframe in error page(s) is something that does 
> not violate standards? Let's not talk about common sense here ;)
>

Anything that is accepted by browsers in an HTML document for 
client-side interpretation can be used. That includes references to 
sub-resources.

Amos