[squid-users] Question: Is it possible adaptation_service_chain from services with different access lists?

[Alex Rousskov]

On 09/26/2016 10:42 AM, Yuri Voinov wrote:
> 26.09.2016 22:25, Alex Rousskov пишет:
>> I assume you meant that Squid should
>> not send service B non-text messages at all.

> And how to do it?

I gave a specific example.


> To adapt the chain is only one access control list.

You are approaching this problem from the wrong angle: adaptation_access
rules are not attached to a specific adaptation service, set, or chain.
Those rules are like routing tables -- they send each message to one of
the existing services, sets, or chains (the first matching rule wins).
This is the same as cache_peer_access rules sending each message to a
specific cache peer. More on that below.


> How can I make a chain of adaptation with
> different acl's for different chained services?

By configuring several chains and then writing adaptation_access rules
to select the right chain for a given message.


>>   adaptation_service_chain vegetarianChain serviceA serviceB
>>
>>   acl messageIsText ...
>>   adaptation_access vegetarianChain messageIsText
>>   adaptation_access serviceA all

> Here from this place can be a bit more detail. 

The above contains everything except for the messageIsText ACL
definition (which I do not know). Please let me know what other details
are missing...


> A service
> receives all of the transactions, and the service B is limited to text
> answers?

That is exactly what the above configuration accomplishes. Service A
receives all messages because this service is present no matter which
adaptation_access rule matches. Service B only receives messageIsText
messages (after they are processed by Service A).


>> 2. Dynamic decision inside ServiceA:
> 
>>    Modify ServiceA to emit an appropriate ICAP X-Next-Services header
>> [for text messages]. Do not forget to configure ServiceA with
>> routing=on! Search for X-Next-Services in squid.conf.documented.

> As I understand it, there is required a modification service code, right?

Yes, unless ServiceA already has some configuration options to
accomplish this.


> And is it possible specific example here:

A specific example for dynamic routing would be service A returning an
ICAP header like this:

  X-Next-Services: serviceB

(when and only when service A wants service B to be applied next). In
this case, Squid configuration becomes trivial:

  adaptation_access serviceA all


> #    routing=on|off|1|0
> #        If set to 'on' or '1', the ICAP service is allowed to
> #        dynamically change the current message adaptation plan by
> #        returning a chain of services to be used next. The services
> #        are specified using the X-Next-Services ICAP response header
> #        value, formatted as a comma-separated list of service names.
> #        Each named service should be configured in squid.conf. Other
> #        services are ignored. An empty X-Next-Services value results
> #        in an empty plan which ends the current adaptation.
> #
> #        Dynamic adaptation plan may cross or cover multiple supported
> #        vectoring points in their natural processing order.
> #
> #        Routing is not allowed by default: the ICAP X-Next-Services
> #        response header is ignored.
> 
> For me personally, this paragraph does not explain anything.

I am sorry to hear that, but I cannot explain it better. Perhaps you can
ask specific questions and/or others can pitch in.



> we can not set
> different access to services in the chain and the chain can have only
> one level of access is the same for all the services within it?

Yes, dynamic routing aside, Squid builds a message adaptation plan and
then follows it. That plan is built at adaptation_access evaluation
time. That evaluation happens once per virgin message at each vectoring
point (REQMOD and RESPMOD). During that evaluation, the first
adaptation_access rule wins and the winning set/chain/service becomes
that adaptation plan.

There are some minor caveats like "down" services and adaptation plans
that span vectoring points, but I do not think they are important in
this context.



> Because then this assertion is contrary to the above.

I do not see a contradiction. What contradicts what, exactly?

Alex.