Thanks for the push in the right direction. Our lan is behind
a firewall. Starting with the info you sent me, and digging further
into the docs, I experimented with various settings until I've found
one I think is working - at least it's communicating the the keyserver!
I used the explicit IP address for the keyserver - 204.152.186.139,
and set the port to 23 (telnet). Doing only one or the other did not
fix the problem.
Thanks for the help! I'll be back if this doesn't work.
Regards,
Russ
Michael Heldebrant wrote:
> On 15 Aug 2001 12:45:31 -0500, Russell D Cook wrote:
> > Debian is 2.2r2, upgraded to testing/unstable.
> > Kernel is 2.2.18pre21.
> > Library is libc-2.2.3-9.
> >
> >
> >
> > Michael Heldebrant wrote:
> >
> > > On 15 Aug 2001 12:06:46 -0500, Russell D Cook wrote:
> > > > I installed the debian package - I figured there would be less
> > > > likelihood
> > > > of problems that way. Thanks for the reply.
> > > > Still need help.
> > > >
> > > > Regards,
> > > > Russ
> > > >
> > > > Michael Heldebrant wrote:
> > > >
> > > > > On 15 Aug 2001 11:40:16 -0500, Russell D Cook wrote:
> > > > > > I have 3 Sparcs running Debian unstable/testing. I recently
> > > > > > installed
> > > > > > distributed-net from a Debian package. The software is running on
> > > > > > the three machines, but the log files are filled with the following
> > > > > > message:
> > > > > > Network::failed to resolve name "us.v27.distributed.net"
> > > > > > The machines have no problem with ftp or http access to the net, and
> > > > > > are on a lan. The package runs fine on my x86 boxes at home. Is
> > > > > > there
> > > > > > some peculiarity about the distributed-net package with the Sparc
> > > > > > distribution?
> > > > > >
> > > > > > Any help gratefully accepted: I'm storing up many random keys to
> > > > > > check
> > > > > > in.
> > > > > >
> > > > >
> > > > > I once ran into that exact same problem when I was running a glibc
> > > > > version of distnet on a libc system. Did you install the debian
> > > > > package
> > > > > or put your own?
> > >
> > > What version of libc6 (which dselect says it depends on) is the system
> > > running? What release of debian are you running?
>
> Perhaps some previous users have solved it in one way or another for you
> below.
>
> Blatantly stolen from the distributed.net faq-o-matic:
>
> The most common reason is because you are located behind a firewall and
> the client can't get directly out to the internet. There are work
> arounds as described in the next section. Intermittent network errors
> can also occur due to poor conditions on your LAN, poor phone lines, or
> heavy traffic on the internet itself. There have been some problems with
> earlier versions of the client being overly sensitive to response times.
> These problems have been mostly resolved.
>
> If you are getting "Unable to resolve..." messages from the Linux
> client, you may be having a compatibility problem with the "glibc"
> library. There are two common, incompatible versions of glibc: glibc2.0
> and glibc2.1. You will notice that there are two Linux clients with
> "glibc20" and glibc21" in their file names. You must choose the correct
> version in order for name resolution to work. If you are not sure which
> glibc version you have, just try the other client to see if it works
> better.
>
> Starting with build v2.8008-459 of the client, there are now be a single
> unified Linux binary (for each processor architecture type), instead of
> separate ones for each architecture and library combination. The name
> resolution incompatibilities have been worked around by using "clever"
> dynamic symbol loading techniques, but this didn't work very well
> (problems ranged from segfaults to hanging threads to simply
> not-working).
>
> So, from 2.8011-463 on, the client does not even bother trying to work
> around the insanity introduced by glibc, and instead pipes/parses the
> output of 'host'.
>
> I noticed that (at least on Unix) a running client does not take any
> notice if you change DNS servers. Look out for spurious UDP packets to
> the old nameserver (netstat -tn), and a failure to flush buffers once
> the old nameserver has packed up and gone home. Restarting the client
> will fix this. This applies to any application that uses the ISC
> resolver, which only loads /etc/resolv.conf (into static storage) once.
> If you find that your Linux client is reporting this error, it's because
> you do not have the bind tools installed on your computer. Look for a
> "bind-tools" binary package in whichever packaging format is appropriate
> for your particular flavor of linux.
> Unfortunately, the only alternative to requiring bind-tools would be for
> distributed.net to release multiple, conflicting versions of the client
> for all the various libc permutations that exist.
> To simply set the address manually, also solves the problem. By using
> nslookup or ping, I found the IP address of the name it failed to
> resolve. Then it was just to start the client with:
> dnetc -a 145.89.128.249
> If they change the ip address, or that server goes down, the client will
> fail. So I have the client running in a detached screen. And I check the
> output from time to time.
--
Russell Cook, Engineering Branch
WSR-88D Radar Operations Center
(405)366-6520 x4230
[EMAIL PROTECTED]
begin:vcard
n:Cook;Russell
tel;fax:(405) 366-6555
tel;work:(405) 366-6520 ext 4230
x-mozilla-html:FALSE
adr:;;;;;;
version:2.1
email;internet:[EMAIL PROTECTED]
fn:Russell Cook
end:vcard
