Change in shn response (logging)

[Steve Malenfant <sm...@gmail.com>]

Was doing some testing this morning and noticed that I couldn't find my
traffic by the origin server hostname anymore using our logging system.
While discussing with a few folks, looks like the "shn" field isn't
reporting the origin server hostname under certain circumstances, for
example when used with parent.config.

shn now reports the IP address or hostname used in the parent.config, which
is what we used pqsn/pqsi field before.

In the pull request https://github.com/apache/trafficserver/pull/3860,
there is a workaround using the client/server host header that can be used.
That header contains also a port.

I know we applied the logic of pqsn to shn, but pqsn had a different
meaning than origin server hostname.

pqsnThe proxy request server name; the name of the server that fulfilled
the request.

The PR says that the psqn logic was proper, although I don't think it was
the case for the definition of shn.

shnThe hostname of the origin server.

Few things could happen.
- Revert back the change
- Adjust my logging system (and everybody else maybe)

Any explanation that the 5.x/6.x behavior was causing?

Thanks,

Steve

Re: Change in shn response (logging)

[Steve Malenfant <sm...@gmail.com>]

Yes, that works only if you are doing standard remapping. If you use
parent.config in forward proxy mode, it doesn't work.

I believe the change made might have broken logging for forward proxy.

On Tue, Apr 16, 2019 at 10:32 AM Jeremy Payne <jp...@gmail.com> wrote:

> hmm.. just tested again, whenever ATS(7.1.4/5) polls an upstream
> server(parent or origin), i see an IP in the 'nhi' field.
> for a cache hit, results in a '-' entry.
>
> jeremy
>
> On Tue, Apr 16, 2019 at 8:04 AM Steve Malenfant <sm...@gmail.com>
> wrote:
> >
> > I tried the change a few things here although can't get to same values
> as before.
> >
> > I had to change from the following:
> > shn=%<shh> pqsn=%<pqsn> pqsi=%<pqsi>
> >
> > To (as suggested):
> > shn=%<{Host}cqh> pqsn=%<shn> pqsi=%<nhi>
> >
> > nhi doesn't return anything, shn returns an IP.
> >
> > Parent.config on our "edge" caches looks like:
> > dest_domain=<domain> parent="10.10.10.1:80|0.999; 10.10.10.2
> :80|0.999;68.1.14.152:80|0.999;" secondary_parent=" 10.10.11.1
> :80|0.999; 10.10.10.2:80|0.999;" round_robin=consistent_hash
> go_direct=false qstring=ignore
> >
> > This change definitively removed/changed the pqsn/pqsi/shn logic that
> was there before when parent.config is in use.
> >
> > Steve
> >
> >
> > On Tue, Apr 16, 2019 at 8:44 AM Jeremy Payne <jp...@gmail.com> wrote:
> >>
> >> Doesnt answer your question as to why the change and documentation
> discrepancy.  But in testing I noticed nhi is now the field to use to log
> the upstream ip
> >>
> >>
> >> On Tue, Apr 16, 2019, 7:29 AM Steve Malenfant <sm...@gmail.com>
> wrote:
> >>>
> >>> We pushed some 7.1.x in our production environment. Looks like we need
> to revert that change for our deployment. The documentation doesn't match
> the behavior anymore and seems like I can't get the origin server without
> the port. This does impact our anomaly detection and event alarming that we
> have in place.
> >>>
> >>> I really would like to know the reasoning behind this. Looks like the
> PR was done based on the fact that psqn was empty but user was not using
> parent.config. This is good information for troubleshooting.
> >>>
> >>> Our CDN hierarchy includes edge caches connected to Mid Caches via
> forward proxies (We also have Multi-Site Origin configured via proxying as
> well). shn was "origin hostname", pqsn was "proxy hostname", pqsi was
> "proxy resolved IP".
> >>>
> >>> Steve
> >>>
> >>>
> >>> On Wed, Feb 6, 2019 at 11:43 AM Jeremy Payne <jp...@gmail.com>
> wrote:
> >>>>
> >>>> re: ATS 7.1.x
> >>>>
> >>>> Somewhat related.. I notice that upon polling an upstream server, pqsi
> >>>> does not log the upstream IP.
> >>>> pqsn DOES log the upstream FQDN.
> >>>> If I replace pqsi with 'nhi' then I am able to log upstream IP again.
> >>>>
> >>>>
> >>>>
> >>>> On Mon, Jan 14, 2019 at 1:51 PM Alan Carroll <
> solidwallofcode@oath.com> wrote:
> >>>> >
> >>>> > One of the issues with this is what exactly was the difference
> between `pqsn` and `shn`? Did they different when using parent.config?
> >>>> >
> >>>> > On Fri, Jan 11, 2019 at 11:54 AM Steve Malenfant <
> smalenfant@gmail.com> wrote:
> >>>> >>
> >>>> >> Was doing some testing this morning and noticed that I couldn't
> find my traffic by the origin server hostname anymore using our logging
> system. While discussing with a few folks, looks like the "shn" field isn't
> reporting the origin server hostname under certain circumstances, for
> example when used with parent.config.
> >>>> >>
> >>>> >> shn now reports the IP address or hostname used in the
> parent.config, which is what we used pqsn/pqsi field before.
> >>>> >>
> >>>> >> In the pull request
> https://github.com/apache/trafficserver/pull/3860, there is a workaround
> using the client/server host header that can be used. That header contains
> also a port.
> >>>> >>
> >>>> >> I know we applied the logic of pqsn to shn, but pqsn had a
> different meaning than origin server hostname.
> >>>> >>
> >>>> >> pqsnThe proxy request server name; the name of the server that
> fulfilled the request.
> >>>> >>
> >>>> >> The PR says that the psqn logic was proper, although I don't think
> it was the case for the definition of shn.
> >>>> >>
> >>>> >> shnThe hostname of the origin server.
> >>>> >>
> >>>> >> Few things could happen.
> >>>> >> - Revert back the change
> >>>> >> - Adjust my logging system (and everybody else maybe)
> >>>> >>
> >>>> >> Any explanation that the 5.x/6.x behavior was causing?
> >>>> >>
> >>>> >> Thanks,
> >>>> >>
> >>>> >> Steve
> >>>> >
> >>>> >
> >>>> >
> >>>> > --
> >>>> > Beware the fisherman who's casting out his line in to a dried up
> riverbed.
> >>>> > Oh don't try to tell him 'cause he won't believe. Throw some bread
> to the ducks instead.
> >>>> > It's easier that way. - Genesis : Duke : VI 25-28
>

Re: Change in shn response (logging)

[Jeremy Payne <jp...@gmail.com>]

hmm.. just tested again, whenever ATS(7.1.4/5) polls an upstream
server(parent or origin), i see an IP in the 'nhi' field.
for a cache hit, results in a '-' entry.

jeremy

On Tue, Apr 16, 2019 at 8:04 AM Steve Malenfant <sm...@gmail.com> wrote:
>
> I tried the change a few things here although can't get to same values as before.
>
> I had to change from the following:
> shn=%<shh> pqsn=%<pqsn> pqsi=%<pqsi>
>
> To (as suggested):
> shn=%<{Host}cqh> pqsn=%<shn> pqsi=%<nhi>
>
> nhi doesn't return anything, shn returns an IP.
>
> Parent.config on our "edge" caches looks like:
> dest_domain=<domain> parent="10.10.10.1:80|0.999; 10.10.10.2 :80|0.999;68.1.14.152:80|0.999;" secondary_parent=" 10.10.11.1  :80|0.999; 10.10.10.2:80|0.999;" round_robin=consistent_hash go_direct=false qstring=ignore
>
> This change definitively removed/changed the pqsn/pqsi/shn logic that was there before when parent.config is in use.
>
> Steve
>
>
> On Tue, Apr 16, 2019 at 8:44 AM Jeremy Payne <jp...@gmail.com> wrote:
>>
>> Doesnt answer your question as to why the change and documentation discrepancy.  But in testing I noticed nhi is now the field to use to log the upstream ip
>>
>>
>> On Tue, Apr 16, 2019, 7:29 AM Steve Malenfant <sm...@gmail.com> wrote:
>>>
>>> We pushed some 7.1.x in our production environment. Looks like we need to revert that change for our deployment. The documentation doesn't match the behavior anymore and seems like I can't get the origin server without the port. This does impact our anomaly detection and event alarming that we have in place.
>>>
>>> I really would like to know the reasoning behind this. Looks like the PR was done based on the fact that psqn was empty but user was not using parent.config. This is good information for troubleshooting.
>>>
>>> Our CDN hierarchy includes edge caches connected to Mid Caches via forward proxies (We also have Multi-Site Origin configured via proxying as well). shn was "origin hostname", pqsn was "proxy hostname", pqsi was "proxy resolved IP".
>>>
>>> Steve
>>>
>>>
>>> On Wed, Feb 6, 2019 at 11:43 AM Jeremy Payne <jp...@gmail.com> wrote:
>>>>
>>>> re: ATS 7.1.x
>>>>
>>>> Somewhat related.. I notice that upon polling an upstream server, pqsi
>>>> does not log the upstream IP.
>>>> pqsn DOES log the upstream FQDN.
>>>> If I replace pqsi with 'nhi' then I am able to log upstream IP again.
>>>>
>>>>
>>>>
>>>> On Mon, Jan 14, 2019 at 1:51 PM Alan Carroll <so...@oath.com> wrote:
>>>> >
>>>> > One of the issues with this is what exactly was the difference between `pqsn` and `shn`? Did they different when using parent.config?
>>>> >
>>>> > On Fri, Jan 11, 2019 at 11:54 AM Steve Malenfant <sm...@gmail.com> wrote:
>>>> >>
>>>> >> Was doing some testing this morning and noticed that I couldn't find my traffic by the origin server hostname anymore using our logging system. While discussing with a few folks, looks like the "shn" field isn't reporting the origin server hostname under certain circumstances, for example when used with parent.config.
>>>> >>
>>>> >> shn now reports the IP address or hostname used in the parent.config, which is what we used pqsn/pqsi field before.
>>>> >>
>>>> >> In the pull request https://github.com/apache/trafficserver/pull/3860, there is a workaround using the client/server host header that can be used. That header contains also a port.
>>>> >>
>>>> >> I know we applied the logic of pqsn to shn, but pqsn had a different meaning than origin server hostname.
>>>> >>
>>>> >> pqsnThe proxy request server name; the name of the server that fulfilled the request.
>>>> >>
>>>> >> The PR says that the psqn logic was proper, although I don't think it was the case for the definition of shn.
>>>> >>
>>>> >> shnThe hostname of the origin server.
>>>> >>
>>>> >> Few things could happen.
>>>> >> - Revert back the change
>>>> >> - Adjust my logging system (and everybody else maybe)
>>>> >>
>>>> >> Any explanation that the 5.x/6.x behavior was causing?
>>>> >>
>>>> >> Thanks,
>>>> >>
>>>> >> Steve
>>>> >
>>>> >
>>>> >
>>>> > --
>>>> > Beware the fisherman who's casting out his line in to a dried up riverbed.
>>>> > Oh don't try to tell him 'cause he won't believe. Throw some bread to the ducks instead.
>>>> > It's easier that way. - Genesis : Duke : VI 25-28

Re: Change in shn response (logging)

[Steve Malenfant <sm...@gmail.com>]

I tried the change a few things here although can't get to same values as
before.

I had to change from the following:
shn=%<shh> pqsn=%<pqsn> pqsi=%<pqsi>

To (as suggested):
shn=%<{Host}cqh> pqsn=%<shn> pqsi=%<nhi>

nhi doesn't return anything, shn returns an IP.

Parent.config on our "edge" caches looks like:
dest_domain=<domain> parent="10.10.10.1:80|0.999;
10.10.10.2 :80|0.999;68.1.14.152:80|0.999;" secondary_parent=" 10.10.11.1
:80|0.999; 10.10.10.2:80|0.999;" round_robin=consistent_hash
go_direct=false qstring=ignore

This change definitively removed/changed the pqsn/pqsi/shn logic that was
there before when parent.config is in use.

Steve


On Tue, Apr 16, 2019 at 8:44 AM Jeremy Payne <jp...@gmail.com> wrote:

> Doesnt answer your question as to why the change and documentation
> discrepancy.  But in testing I noticed nhi is now the field to use to log
> the upstream ip
>
>
> On Tue, Apr 16, 2019, 7:29 AM Steve Malenfant <sm...@gmail.com>
> wrote:
>
>> We pushed some 7.1.x in our production environment. Looks like we need to
>> revert that change for our deployment. The documentation doesn't match the
>> behavior anymore and seems like I can't get the origin server without the
>> port. This does impact our anomaly detection and event alarming that we
>> have in place.
>>
>> I really would like to know the reasoning behind this. Looks like the PR
>> was done based on the fact that psqn was empty but user was not using
>> parent.config. This is good information for troubleshooting.
>>
>> Our CDN hierarchy includes edge caches connected to Mid Caches via
>> forward proxies (We also have Multi-Site Origin configured via proxying as
>> well). shn was "origin hostname", pqsn was "proxy hostname", pqsi was
>> "proxy resolved IP".
>>
>> Steve
>>
>>
>> On Wed, Feb 6, 2019 at 11:43 AM Jeremy Payne <jp...@gmail.com> wrote:
>>
>>> re: ATS 7.1.x
>>>
>>> Somewhat related.. I notice that upon polling an upstream server, pqsi
>>> does not log the upstream IP.
>>> pqsn DOES log the upstream FQDN.
>>> If I replace pqsi with 'nhi' then I am able to log upstream IP again.
>>>
>>>
>>>
>>> On Mon, Jan 14, 2019 at 1:51 PM Alan Carroll <so...@oath.com>
>>> wrote:
>>> >
>>> > One of the issues with this is what exactly was the difference between
>>> `pqsn` and `shn`? Did they different when using parent.config?
>>> >
>>> > On Fri, Jan 11, 2019 at 11:54 AM Steve Malenfant <sm...@gmail.com>
>>> wrote:
>>> >>
>>> >> Was doing some testing this morning and noticed that I couldn't find
>>> my traffic by the origin server hostname anymore using our logging system.
>>> While discussing with a few folks, looks like the "shn" field isn't
>>> reporting the origin server hostname under certain circumstances, for
>>> example when used with parent.config.
>>> >>
>>> >> shn now reports the IP address or hostname used in the parent.config,
>>> which is what we used pqsn/pqsi field before.
>>> >>
>>> >> In the pull request https://github.com/apache/trafficserver/pull/3860,
>>> there is a workaround using the client/server host header that can be used.
>>> That header contains also a port.
>>> >>
>>> >> I know we applied the logic of pqsn to shn, but pqsn had a different
>>> meaning than origin server hostname.
>>> >>
>>> >> pqsnThe proxy request server name; the name of the server that
>>> fulfilled the request.
>>> >>
>>> >> The PR says that the psqn logic was proper, although I don't think it
>>> was the case for the definition of shn.
>>> >>
>>> >> shnThe hostname of the origin server.
>>> >>
>>> >> Few things could happen.
>>> >> - Revert back the change
>>> >> - Adjust my logging system (and everybody else maybe)
>>> >>
>>> >> Any explanation that the 5.x/6.x behavior was causing?
>>> >>
>>> >> Thanks,
>>> >>
>>> >> Steve
>>> >
>>> >
>>> >
>>> > --
>>> > Beware the fisherman who's casting out his line in to a dried up
>>> riverbed.
>>> > Oh don't try to tell him 'cause he won't believe. Throw some bread to
>>> the ducks instead.
>>> > It's easier that way. - Genesis : Duke : VI 25-28
>>>
>>

Re: Change in shn response (logging)

[Jeremy Payne <jp...@gmail.com>]

Doesnt answer your question as to why the change and documentation
discrepancy.  But in testing I noticed nhi is now the field to use to log
the upstream ip


On Tue, Apr 16, 2019, 7:29 AM Steve Malenfant <sm...@gmail.com> wrote:

> We pushed some 7.1.x in our production environment. Looks like we need to
> revert that change for our deployment. The documentation doesn't match the
> behavior anymore and seems like I can't get the origin server without the
> port. This does impact our anomaly detection and event alarming that we
> have in place.
>
> I really would like to know the reasoning behind this. Looks like the PR
> was done based on the fact that psqn was empty but user was not using
> parent.config. This is good information for troubleshooting.
>
> Our CDN hierarchy includes edge caches connected to Mid Caches via forward
> proxies (We also have Multi-Site Origin configured via proxying as well).
> shn was "origin hostname", pqsn was "proxy hostname", pqsi was "proxy
> resolved IP".
>
> Steve
>
>
> On Wed, Feb 6, 2019 at 11:43 AM Jeremy Payne <jp...@gmail.com> wrote:
>
>> re: ATS 7.1.x
>>
>> Somewhat related.. I notice that upon polling an upstream server, pqsi
>> does not log the upstream IP.
>> pqsn DOES log the upstream FQDN.
>> If I replace pqsi with 'nhi' then I am able to log upstream IP again.
>>
>>
>>
>> On Mon, Jan 14, 2019 at 1:51 PM Alan Carroll <so...@oath.com>
>> wrote:
>> >
>> > One of the issues with this is what exactly was the difference between
>> `pqsn` and `shn`? Did they different when using parent.config?
>> >
>> > On Fri, Jan 11, 2019 at 11:54 AM Steve Malenfant <sm...@gmail.com>
>> wrote:
>> >>
>> >> Was doing some testing this morning and noticed that I couldn't find
>> my traffic by the origin server hostname anymore using our logging system.
>> While discussing with a few folks, looks like the "shn" field isn't
>> reporting the origin server hostname under certain circumstances, for
>> example when used with parent.config.
>> >>
>> >> shn now reports the IP address or hostname used in the parent.config,
>> which is what we used pqsn/pqsi field before.
>> >>
>> >> In the pull request https://github.com/apache/trafficserver/pull/3860,
>> there is a workaround using the client/server host header that can be used.
>> That header contains also a port.
>> >>
>> >> I know we applied the logic of pqsn to shn, but pqsn had a different
>> meaning than origin server hostname.
>> >>
>> >> pqsnThe proxy request server name; the name of the server that
>> fulfilled the request.
>> >>
>> >> The PR says that the psqn logic was proper, although I don't think it
>> was the case for the definition of shn.
>> >>
>> >> shnThe hostname of the origin server.
>> >>
>> >> Few things could happen.
>> >> - Revert back the change
>> >> - Adjust my logging system (and everybody else maybe)
>> >>
>> >> Any explanation that the 5.x/6.x behavior was causing?
>> >>
>> >> Thanks,
>> >>
>> >> Steve
>> >
>> >
>> >
>> > --
>> > Beware the fisherman who's casting out his line in to a dried up
>> riverbed.
>> > Oh don't try to tell him 'cause he won't believe. Throw some bread to
>> the ducks instead.
>> > It's easier that way. - Genesis : Duke : VI 25-28
>>
>

Re: Change in shn response (logging)

[Steve Malenfant <sm...@gmail.com>]

We pushed some 7.1.x in our production environment. Looks like we need to
revert that change for our deployment. The documentation doesn't match the
behavior anymore and seems like I can't get the origin server without the
port. This does impact our anomaly detection and event alarming that we
have in place.

I really would like to know the reasoning behind this. Looks like the PR
was done based on the fact that psqn was empty but user was not using
parent.config. This is good information for troubleshooting.

Our CDN hierarchy includes edge caches connected to Mid Caches via forward
proxies (We also have Multi-Site Origin configured via proxying as well).
shn was "origin hostname", pqsn was "proxy hostname", pqsi was "proxy
resolved IP".

Steve


On Wed, Feb 6, 2019 at 11:43 AM Jeremy Payne <jp...@gmail.com> wrote:

> re: ATS 7.1.x
>
> Somewhat related.. I notice that upon polling an upstream server, pqsi
> does not log the upstream IP.
> pqsn DOES log the upstream FQDN.
> If I replace pqsi with 'nhi' then I am able to log upstream IP again.
>
>
>
> On Mon, Jan 14, 2019 at 1:51 PM Alan Carroll <so...@oath.com>
> wrote:
> >
> > One of the issues with this is what exactly was the difference between
> `pqsn` and `shn`? Did they different when using parent.config?
> >
> > On Fri, Jan 11, 2019 at 11:54 AM Steve Malenfant <sm...@gmail.com>
> wrote:
> >>
> >> Was doing some testing this morning and noticed that I couldn't find my
> traffic by the origin server hostname anymore using our logging system.
> While discussing with a few folks, looks like the "shn" field isn't
> reporting the origin server hostname under certain circumstances, for
> example when used with parent.config.
> >>
> >> shn now reports the IP address or hostname used in the parent.config,
> which is what we used pqsn/pqsi field before.
> >>
> >> In the pull request https://github.com/apache/trafficserver/pull/3860,
> there is a workaround using the client/server host header that can be used.
> That header contains also a port.
> >>
> >> I know we applied the logic of pqsn to shn, but pqsn had a different
> meaning than origin server hostname.
> >>
> >> pqsnThe proxy request server name; the name of the server that
> fulfilled the request.
> >>
> >> The PR says that the psqn logic was proper, although I don't think it
> was the case for the definition of shn.
> >>
> >> shnThe hostname of the origin server.
> >>
> >> Few things could happen.
> >> - Revert back the change
> >> - Adjust my logging system (and everybody else maybe)
> >>
> >> Any explanation that the 5.x/6.x behavior was causing?
> >>
> >> Thanks,
> >>
> >> Steve
> >
> >
> >
> > --
> > Beware the fisherman who's casting out his line in to a dried up
> riverbed.
> > Oh don't try to tell him 'cause he won't believe. Throw some bread to
> the ducks instead.
> > It's easier that way. - Genesis : Duke : VI 25-28
>

Re: Change in shn response (logging)

[Jeremy Payne <jp...@gmail.com>]

re: ATS 7.1.x

Somewhat related.. I notice that upon polling an upstream server, pqsi
does not log the upstream IP.
pqsn DOES log the upstream FQDN.
If I replace pqsi with 'nhi' then I am able to log upstream IP again.



On Mon, Jan 14, 2019 at 1:51 PM Alan Carroll <so...@oath.com> wrote:
>
> One of the issues with this is what exactly was the difference between `pqsn` and `shn`? Did they different when using parent.config?
>
> On Fri, Jan 11, 2019 at 11:54 AM Steve Malenfant <sm...@gmail.com> wrote:
>>
>> Was doing some testing this morning and noticed that I couldn't find my traffic by the origin server hostname anymore using our logging system. While discussing with a few folks, looks like the "shn" field isn't reporting the origin server hostname under certain circumstances, for example when used with parent.config.
>>
>> shn now reports the IP address or hostname used in the parent.config, which is what we used pqsn/pqsi field before.
>>
>> In the pull request https://github.com/apache/trafficserver/pull/3860, there is a workaround using the client/server host header that can be used. That header contains also a port.
>>
>> I know we applied the logic of pqsn to shn, but pqsn had a different meaning than origin server hostname.
>>
>> pqsnThe proxy request server name; the name of the server that fulfilled the request.
>>
>> The PR says that the psqn logic was proper, although I don't think it was the case for the definition of shn.
>>
>> shnThe hostname of the origin server.
>>
>> Few things could happen.
>> - Revert back the change
>> - Adjust my logging system (and everybody else maybe)
>>
>> Any explanation that the 5.x/6.x behavior was causing?
>>
>> Thanks,
>>
>> Steve
>
>
>
> --
> Beware the fisherman who's casting out his line in to a dried up riverbed.
> Oh don't try to tell him 'cause he won't believe. Throw some bread to the ducks instead.
> It's easier that way. - Genesis : Duke : VI 25-28

Re: Change in shn response (logging)

[Alan Carroll <so...@oath.com>]

One of the issues with this is what exactly was the difference between
`pqsn` and `shn`? Did they different when using parent.config?

On Fri, Jan 11, 2019 at 11:54 AM Steve Malenfant <sm...@gmail.com>
wrote:

> Was doing some testing this morning and noticed that I couldn't find my
> traffic by the origin server hostname anymore using our logging system.
> While discussing with a few folks, looks like the "shn" field isn't
> reporting the origin server hostname under certain circumstances, for
> example when used with parent.config.
>
> shn now reports the IP address or hostname used in the parent.config,
> which is what we used pqsn/pqsi field before.
>
> In the pull request https://github.com/apache/trafficserver/pull/3860,
> there is a workaround using the client/server host header that can be used.
> That header contains also a port.
>
> I know we applied the logic of pqsn to shn, but pqsn had a different
> meaning than origin server hostname.
>
> pqsnThe proxy request server name; the name of the server that fulfilled
> the request.
>
> The PR says that the psqn logic was proper, although I don't think it was
> the case for the definition of shn.
>
> shnThe hostname of the origin server.
>
> Few things could happen.
> - Revert back the change
> - Adjust my logging system (and everybody else maybe)
>
> Any explanation that the 5.x/6.x behavior was causing?
>
> Thanks,
>
> Steve
>


-- 
*Beware the fisherman who's casting out his line in to a dried up riverbed.*
*Oh don't try to tell him 'cause he won't believe. Throw some bread to the
ducks instead.*
*It's easier that way. *- Genesis : Duke : VI 25-28