How to redirect all squid's error pages to one?

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

How to redirect all squid's error pages to one?

dijxie

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/

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?

-- 
Greets, Dijx

_______________________________________________
squid-users mailing list
[hidden email]
http://lists.squid-cache.org/listinfo/squid-users
Reply | Threaded
Open this post in threaded view
|

Re: How to redirect all squid's error pages to one?

Matus UHLAR - fantomas
On 19.05.17 14:44, Dijxie wrote:
>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/
>
>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?

no, unless using icap/ecap.

But what's the point to direct all error messages (with language
autodection) into one, when you also want to make them different by
javascript?
--
Matus UHLAR - fantomas, [hidden email] ; http://www.fantomas.sk/
Warning: I wish NOT to receive e-mail advertising to this address.
Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.
It's now safe to throw off your computer.
_______________________________________________
squid-users mailing list
[hidden email]
http://lists.squid-cache.org/listinfo/squid-users
Reply | Threaded
Open this post in threaded view
|

Re: How to redirect all squid's error pages to one?

Amos Jeffries
Administrator
In reply to this post by dijxie
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
[hidden email]
http://lists.squid-cache.org/listinfo/squid-users
Reply | Threaded
Open this post in threaded view
|

Re: How to redirect all squid's error pages to one?

dijxie
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
[hidden email]
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.

Thank You.

-- 
Greets, Dijx.

_______________________________________________
squid-users mailing list
[hidden email]
http://lists.squid-cache.org/listinfo/squid-users
Reply | Threaded
Open this post in threaded view
|

Re: How to redirect all squid's error pages to one?

Amos Jeffries
Administrator
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
>> [hidden email]
>> 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.

Amos

_______________________________________________
squid-users mailing list
[hidden email]
http://lists.squid-cache.org/listinfo/squid-users
Reply | Threaded
Open this post in threaded view
|

Re: How to redirect all squid's error pages to one?

dijxie
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
[hidden email]
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.

Amos

_______________________________________________
squid-users mailing list
[hidden email]
http://lists.squid-cache.org/listinfo/squid-users

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.
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 ;)

Greets, Dijx

_______________________________________________
squid-users mailing list
[hidden email]
http://lists.squid-cache.org/listinfo/squid-users
Reply | Threaded
Open this post in threaded view
|

Re: How to redirect all squid's error pages to one?

Amos Jeffries
Administrator
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
>>>> [hidden email]
>>>> 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

_______________________________________________
squid-users mailing list
[hidden email]
http://lists.squid-cache.org/listinfo/squid-users