-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 26.09.2016 23:16, 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. Ahaaaaaaaaa. I.e., I can specify chain_A with own access rules and one service_A in chain, and then chain_B, also with own access rules and one service_B, and, finally, specify chain_C with chain_A+chain_B and with access "all". Right? > > > >>> 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. There would not be an extra circuit or illustration. Not quite clear exactly what is meant. > > > > >> 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. Yes, right. > > > > >> Because then this assertion is contrary to the above. > > I do not see a contradiction. What contradicts what, exactly? Ah, this statement is removed. :) Picture clearer :) > > > Alex. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBCAAGBQJX6VuXAAoJENNXIZxhPexG9lYIAKXdIFgCgxk8/dYa+SW5wHZt dQQZwaff4IRFzXsIZpxSIL9JxL9r4ISoExf7bsVtA4aFEi/XvNqJgCNMiAsvr+Mh XeXkIeI1OILY17Ol0YD7rZLfmpcTDumUWpumgOnCfh9Bi20lRwGh41oi/KyH3yY3 CS4oh3pGTUWCB3WpwTqiX2GL5HBrasQT21qh4ehLhM8IP0Hkql/AUAWImWZxxvLl j9MJPqJew5lzMAhNRchCh2erzk1jZMFVof+7JEvywIlj1AEUIgvc3oVchdbcuuq2 eS+7amOxkZ1J+Bi9unIZV5Ni+iersDzVCqaDaTEDc2Eiy2rKKiUgnujJXTCyAX0= =FjfB -----END PGP SIGNATURE-----
Attachment:
0x613DEC46.asc
Description: application/pgp-keys
_______________________________________________ squid-users mailing list squid-users@xxxxxxxxxxxxxxxxxxxxx http://lists.squid-cache.org/listinfo/squid-users
