Re: [wccpd-devel] kernel wccp support

[Blues <bl...@ds...>]

On 30 Jan 2002, Eduardo J. Blanco wrote:
> Don't worry about the flame.

:)

> IMHO, the user shouldn't need to call these scripts directly (because
> wccpd will get confused), and they are not program data either.  That's
> why I put it libexec (from ./configure --help):
> --libexecdir=3DDIR        program executables in DIR [EPREFIX/libexec]
> The way I see it, these scripts are auxiliary executables needed -only-
> by wccpd.

ok - let it be...
It's quite good choice.

>     This 2 thing are connected (in my mind ;)
>     I think that wccpd should call all of the externel programs (ip, ip=
vs).=20
>     Only iptables/ipchains should stay for the end-user.
>     Now - if it will be done (should, I think...):
>     1. one config-file will drive everything. eg. config:
>     cache {
>     	server proxy1.bla.bla.pl;
>     	wccp-protocol 1;
>     	encapsulation gre;
>     	fw-mark 0x80;
>     }
>     2. scripts location will be no problem anymore (no scripts :)  )
>     3. system log will be more reliable - now only connection of new ca=
che is=20
>     noticed. Disconnection isn't. Some diagnostics can be made...? :)
> Sigh... I really don't like this option.  I always wanted to make wccpd
> as portable as possible, that's why I split the OS related stuff from
> the WCCP protocol itself.  You could write similar scripts for BSD, or
> whatever.  Making wccpd call the programs directly only imposes a
> limitation, IMHO.

but... you can make it portable in building stage... Only few functions=20
will differ.=20

You can still keep possibility to execute external scripts ,eg. in config=
:

enable-cache-script:	/bla/bla/script=20
...

You can have flexible and powerfull tool still.

> OTOH, some of the scripts for WCCP v2 will need to call
> ipchains/iptables to cope with dynamic service groups. (ie. services
> described by the webcache dynamically)
> I'm planning to add a config file for WCCPv2, as I have pretty much no
> other option.  I'll take the chance to do something like you suggested.

As you see you don't have choice :)

>     Sure - almost everything can be done by smarter script, but... its =
not=20
>     "clean" solution. Point 3 can't be done in current model.
>    =20
>     Disadvantages of making it that way:
>     - it will be external-programs-dependent
>     - no easy way to change proxies on-fly. Solution of that can be som=
e=20
>     socket or something like that + some small external program for=20
>     management.
>    =20
>     Is it clear?
> About point #3, there are 3 conditions for a cache to 'leave':
> 1) Timeout - presumably the cache is down or rebooted, and it stopped
> sending correct I_AM_HERE messages.
> 2) The designated cache took it out of the assignment hash.
> 3) wccpd is about to exit.
> In all three cases, you should see something like:
> WebCache at xxx.xxx.xxx.xxx disabled
> Let me know if you don't.

It seems I don't.

I've run manualy scripts and no matter how long I left down state - no=20
sign in logs.

> I could change those messages to something like:
> WebCache at xxx.xxx.xxx.xxx expired
> WebCache at xxx.xxx.xxx.xxx disabled by designated WebCache
> WebCache at xxx.xxx.xxx.xxx disabled by wccpd shutdown

This would be cool. More information is better information :)


--=20
---------------------------------
pozdr.  Pawe=B3 Go=B3aszewski       =20
---------------------------------
CPU not found - software emulation...