Re: DCC digest, Vol 1 #1007 - 1 msg

View: New views
6 Messages — Rating Filter:   Alert me  

Parent Message unknown Re: DCC digest, Vol 1 #1007 - 1 msg

by PeakPeak Customer Service :: Rate this Message:

Reply (Restricted by the Administrator) | Reply to Author | View Threaded | Show Only this Message

I'm getting this after a few seconds:

# /var/dcc/libexec/updatedcc
stopping; please wait
#

Just quits.

Chris


On 4/21/08 1:05 PM, "dcc-request@..." <dcc-request@...>
wrote:

> Send DCC mailing list submissions to
> dcc@...
>
> To subscribe or unsubscribe via the World Wide Web, visit
> http://www.rhyolite.com/mailman/listinfo/dcc
> or, via email, send a message with subject or body 'help' to
> dcc-request@...
>
> You can reach the person managing the list at
> dcc-admin@...
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of DCC digest..."
>
>
> Today's Topics:
>
>    1. DCC version 1.3.88/2.3.88 released (Vernon Schryver)
>
> --__--__--
>
> Message: 1
> Date: Mon, 21 Apr 2008 00:22:53 GMT
> From: Vernon Schryver <vjs@...>
> To: DCC@...
> Subject: DCC version 1.3.88/2.3.88 released
>
> Version 1.3.88 of the DCC source is in
> http://www.dcc-servers.net/dcc/source/dcc.tar.Z  and
> http://www.rhyolite.com/anti-spam/dcc/source/dcc.tar.Z
>
> Commercial version 2.3.88 of the DCC Reputation code is in the usual place.
>
> The CHANGES file starts with
>     Repair rate limiting on dccd syslog complaints.
>     Relax dccd load sharing enough to prevent spurious timeouts by
> keepalive timers and some troubles with flood connections.
>
> /var/dcc/libexec/updatedcc should automagically fetch, build, and
> install the commercial or free version, depending on the .updatedcc_pfile
> file, unless you have installed a version of Linux with the broken
> default `sort` collating sequence since last upgrading.  If so, an
> easy way to get the old updatedcc script working is to delete the
> entire /var/dcc/build/dcc directory before running updatedcc.
>
>
> Vernon Schryver    vjs@...
>
>
> --__--__--
>
> _______________________________________________
> DCC mailing list      DCC@...
> http://www.rhyolite.com/mailman/listinfo/dcc
>
>
> End of DCC Digest
>


_______________________________________________
DCC mailing list      DCC@...
http://www.rhyolite.com/mailman/listinfo/dcc

Re: DCC digest, Vol 1 #1007 - 1 msg

by Vernon Schryver :: Rate this Message:

Reply (Restricted by the Administrator) | Reply to Author | View Threaded | Show Only this Message

> From: PeakPeak Customer Service <support@...>

> I'm getting this after a few seconds:
>
> # /var/dcc/libexec/updatedcc
> stopping; please wait
> #
>
> Just quits.

Are there any clues from debugging, which can be turned on with
    /var/dcc/libexec/updatedcc -x


Vernon Schryver    vjs@...
_______________________________________________
DCC mailing list      DCC@...
http://www.rhyolite.com/mailman/listinfo/dcc

Re: DCC digest, Vol 1 #1007 - 1 msg

by Vernon Schryver :: Rate this Message:

Reply (Restricted by the Administrator) | Reply to Author | View Threaded | Show Only this Message

> From: PeakPeak Customer Service <support@...>

> I'm getting this after a few seconds:
>
> # /var/dcc/libexec/updatedcc
> stopping; please wait
> #
>
> Just quits.

I've released version 1.3.90 which I hope fixes that problem.

Updatedcc failed after shutting down the localhost DCC server and
finding no working server and when the environment variable
DCC_UPDATEDCC_FAST is not set to "yes".  The easiest work-around
is to add the public DCC servers to the local /var/dcc/map file
with `cdcc "add dcc1.dcc-servers.net RTT+1000 ms"`  Besides working
around the updatedcc problem, that uses the public DCC servers
as backups for the local server.


Vernon Schryver    vjs@...
_______________________________________________
DCC mailing list      DCC@...
http://www.rhyolite.com/mailman/listinfo/dcc

Re: DCC digest, Vol 1 #1007 - 1 msg

by William Taylor-4 :: Rate this Message:

Reply (Restricted by the Administrator) | Reply to Author | View Threaded | Show Only this Message

Vernon Schryver wrote:

>> From: PeakPeak Customer Service <support@...>
>>    
>
>  
>> I'm getting this after a few seconds:
>>
>> # /var/dcc/libexec/updatedcc
>> stopping; please wait
>> #
>>
>> Just quits.
>>    
>
> I've released version 1.3.90 which I hope fixes that problem.
>
> Updatedcc failed after shutting down the localhost DCC server and
> finding no working server and when the environment variable
> DCC_UPDATEDCC_FAST is not set to "yes".  The easiest work-around
> is to add the public DCC servers to the local /var/dcc/map file
> with `cdcc "add dcc1.dcc-servers.net RTT+1000 ms"`  Besides working
> around the updatedcc problem, that uses the public DCC servers
> as backups for the local server.
>
>
> Vernon Schryver    vjs@...
> _______________________________________________
> DCC mailing list      DCC@...
> http://www.rhyolite.com/mailman/listinfo/dcc
>
>  
I am having the same sort of problem. dcc just stops working all of a
sudden. Can't figure out why

r 21 21:18:26 lds dccifd[9887]: continue not asking DCC 3 seconds after
failure
Apr 21 21:18:27 lds dccifd[9887]: continue not asking DCC 2 seconds
after failure
Apr 21 21:18:27 lds dccifd[9887]: continue not asking DCC 2 seconds
after failure
Apr 21 21:18:27 lds dccifd[9887]: continue not asking DCC 2 seconds
after failure
Apr 21 21:18:29 lds dccifd[9887]: no working DCC
serversdcc1.dcc-servers.net dcc2.dcc-servers.net dcc3.dcc-servers.net
... at 194.228.41.73 192.135.10.19
Apr 21 21:18:29 lds dccifd[9887]: no working DCC
serversdcc1.dcc-servers.net dcc2.dcc-servers.net dcc3.dcc-servers.net
... at 194.228.41.73 192.135.10.19
Apr 21 21:18:29 lds dccifd[9887]: no working DCC
serversdcc1.dcc-servers.net dcc2.dcc-servers.net dcc3.dcc-servers.net
... at 194.228.41.73 192.135.10.19
Apr 21 21:18:29 lds dccifd[9887]: no working DCC
serversdcc1.dcc-servers.net dcc2.dcc-servers.net dcc3.dcc-servers.net
... at 194.228.41.73 192.135.10.19

[root@lds dcc]# cdcc stats
no working DCC serversdcc1.dcc-servers.net dcc2.dcc-servers.net
dcc3.dcc-servers.net ... at 194.228.41.73 192.135.10.19
 ?

I manually upgrade to the latest version and that didn't help. I did a
tcpdump from my local machine and from one of the public mirrors I have
access to and I see traffic getting there and back. Just things aren't
working.
Any ideas?

Thanks,
 William

_______________________________________________
DCC mailing list      DCC@...
http://www.rhyolite.com/mailman/listinfo/dcc

Re: DCC digest, Vol 1 #1007 - 1 msg

by Vernon Schryver :: Rate this Message:

Reply (Restricted by the Administrator) | Reply to Author | View Threaded | Show Only this Message

> From: William Taylor <williamt@...>

> I am having the same sort of problem. dcc just stops working all of a
> sudden. Can't figure out why
>
> r 21 21:18:26 lds dccifd[9887]: continue not asking DCC 3 seconds after
> failure

What is it that stops working, the shell script updatedcc or the
daemon dccifd's access to the public DCC servers?


> I manually upgrade to the latest version and that didn't help. I did a
> tcpdump from my local machine and from one of the public mirrors I have
> access to and I see traffic getting there and back. Just things aren't
> working.
> Any ideas?

There are two common causes for not getting DCC results:

  1. a firewall that blocks responses sent by the servers from their
      UPD port 627 to the DCC client (e.g. dccifd).

  2. triggering the DoS defenses of the public DCC servers by sending
      too many requests, most often because of the use of the 3+ year
      old version of the client code redistributed by Linux repackagers.

You can check to see whether your DCC client code can hear the public
servers with `cdcc info`.  If they can't, there will be complaints about
"not answering" for all of the dozen servers that your client is trying
to use.


Judging from counts on three of the servers, a client at 206.81.96.54
is sending a few requests and NOPs typical of small tests.

206.81.97.109 is also currently (April 22, 06:30 UTC) making a few tests.

A client at  206.81.96.33 has sent somewhat more than 2000 requests and
perhaps 1000 NOPs.  It is using version #8 of the DCC client-server
protocol, which implies that it is not use ancient version.  Its last
request was at 02:08:40, and since then has probably sent only NOPs.
My guess is that a firewall of some sort has been blocking responses
from UDP port 6277 from at least 64.124.52.0/24 and 209.169.14.0/24 to
dccifd at 206.81.96.33 from about 02:10 UTC.


Vernon Schryver    vjs@...
_______________________________________________
DCC mailing list      DCC@...
http://www.rhyolite.com/mailman/listinfo/dcc

Re: DCC digest, Vol 1 #1007 - 1 msg

by William Taylor-4 :: Rate this Message:

Reply (Restricted by the Administrator) | Reply to Author | View Threaded | Show Only this Message

Vernon Schryver wrote:

>> From: William Taylor <williamt@...>
>>    
>
>  
>> I am having the same sort of problem. dcc just stops working all of a
>> sudden. Can't figure out why
>>
>> r 21 21:18:26 lds dccifd[9887]: continue not asking DCC 3 seconds after
>> failure
>>    
>
> What is it that stops working, the shell script updatedcc or the
> daemon dccifd's access to the public DCC servers?
>
>
>  
>> I manually upgrade to the latest version and that didn't help. I did a
>> tcpdump from my local machine and from one of the public mirrors I have
>> access to and I see traffic getting there and back. Just things aren't
>> working.
>> Any ideas?
>>    
>
> There are two common causes for not getting DCC results:
>
>   1. a firewall that blocks responses sent by the servers from their
>       UPD port 627 to the DCC client (e.g. dccifd).
>
>   2. triggering the DoS defenses of the public DCC servers by sending
>       too many requests, most often because of the use of the 3+ year
>       old version of the client code redistributed by Linux repackagers.
>
> You can check to see whether your DCC client code can hear the public
> servers with `cdcc info`.  If they can't, there will be complaints about
> "not answering" for all of the dozen servers that your client is trying
> to use.
>
>
> Judging from counts on three of the servers, a client at 206.81.96.54
> is sending a few requests and NOPs typical of small tests.
>
> 206.81.97.109 is also currently (April 22, 06:30 UTC) making a few tests.
>
> A client at  206.81.96.33 has sent somewhat more than 2000 requests and
> perhaps 1000 NOPs.  It is using version #8 of the DCC client-server
> protocol, which implies that it is not use ancient version.  Its last
> request was at 02:08:40, and since then has probably sent only NOPs.
> My guess is that a firewall of some sort has been blocking responses
> from UDP port 6277 from at least 64.124.52.0/24 and 209.169.14.0/24 to
> dccifd at 206.81.96.33 from about 02:10 UTC.
>
>
> Vernon Schryver    vjs@...
> _______________________________________________
> DCC mailing list      DCC@...
> http://www.rhyolite.com/mailman/listinfo/dcc
>
>  
Last night I was guessing that I was sending to my requests out from
206.81.96.33 and things were getting autoblocked.
I installed a temp server at 206.81.96.54 which seemed to make the dcc
client happy again. I also added rules this morning
for the firewall stuff on .33. 206.81.97.109 is a colo customer running
their own mailserver.
BTW I ordered the new server for the mirror yesterday so that should be
here soon.
Do I need to have an official server-id for 206.81.96.54?

Thanks,
  William

_______________________________________________
DCC mailing list      DCC@...
http://www.rhyolite.com/mailman/listinfo/dcc