Login prompt very slow
thu...@my-deja.com
to get to the login prompt(via telnet/ftp) on one m/c on LAN takes
+20secs. It is nothing to do with the n/w because other m/cs on the
same LAN only takes 1-2secs. Ping gives same results as the other m/cs.
Any idea of what's happening and/or hint for a fix ?
thanks.
thushara
Sent via Deja.com http://www.deja.com/
Before you buy.
Scott Taylor
>
> using uw7.1.1 on compaq proliant 1600.
> to get to the login prompt(via telnet/ftp) on one m/c on LAN takes
> +20secs. It is nothing to do with the n/w because other m/cs on the
> same LAN only takes 1-2secs. Ping gives same results as the other m/cs.
This seems to be popping up a lot lately. Isn't there a TA for this
yet?
I believe: could be to do with your /etc/resolv.conf file, but I'm not
sure what you mean by an m/c or n/w or m/cs (my ignorance I guess)
/etc/resolv.conf should have this line:
hostresorder local bind
There may be more, you can search for 'slow telnet' or 'slow network' in
this news group and find lots of this.
GL
--
Scott Taylor
MIS, MAAX Westco Inc.
Tony Lawrence
>
> using uw7.1.1 on compaq proliant 1600.
> to get to the login prompt(via telnet/ftp) on one m/c on LAN takes
> +20secs. It is nothing to do with the n/w because other m/cs on the
> same LAN only takes 1-2secs. Ping gives same results as the other m/cs.
The telnetd on the server wants to resolve the host name of that
machine and isn't finding it. Add that machine to /etc/hosts or
DNS.
--
Tony Lawrence (to...@aplawrence.com)
SCO/Linux articles, help, book reviews, tests,
job listings and more : http://www.pcunix.com
Tony Lawrence
>
> thu...@my-deja.com wrote:
> >
> > using uw7.1.1 on compaq proliant 1600.
> > to get to the login prompt(via telnet/ftp) on one m/c on LAN takes
> > +20secs. It is nothing to do with the n/w because other m/cs on the
> > same LAN only takes 1-2secs. Ping gives same results as the other m/cs.
>
> yet?
I don't see one, but it's in both http://aplawrence.com/SCOFAQ/
and http://www.zenez.com/cgi-bin/scouw7faq/faq.pl
Ken Wolff
>thu...@my-deja.com wrote:
> >
> > using uw7.1.1 on compaq proliant 1600.
> > to get to the login prompt(via telnet/ftp) on one m/c on LAN takes
> > +20secs. It is nothing to do with the n/w because other m/cs on the
> > same LAN only takes 1-2secs. Ping gives same results as the other m/cs.
>
>This seems to be popping up a lot lately. Isn't there a TA for this
>yet?
>sure what you mean by an m/c or n/w or m/cs (my ignorance I guess)
>
>/etc/resolv.conf should have this line:
>hostresorder local bind
>
>There may be more, you can search for 'slow telnet' or 'slow network' in
>this news group and find lots of this.
>
>GL
>
>--
>Scott Taylor
>MIS, MAAX Westco Inc.
I think the TA for this would be "SCO....Fix this problem!!!!!!!" This
does not happen on any version of Linux we're running. Also, what's the
purpose of doing such a reverse lookup if, after 2 minutes of trying a
reverse lookup and failing, you still let the offending party in?
Can anyone tell me where this is a problem other than on SCO products?
Geez, just fix it!
Of course, that's just my opinion, I could be wrong!
Ken
Bill Vermillion
Ken Wolff <ke...@cscc.maximus.com> wrote:
>At 04:30 PM 10/5/00 -0700, Scott Taylor wrote:
>>thu...@my-deja.com wrote:
>> > using uw7.1.1 on compaq proliant 1600.
>> > to get to the login prompt(via telnet/ftp) on one m/c on LAN takes
>> > +20secs. It is nothing to do with the n/w because other m/cs on the
>> > same LAN only takes 1-2secs. Ping gives same results as the other m/cs.
>>This seems to be popping up a lot lately. Isn't there a TA for this
>>yet?
>>There may be more, you can search for 'slow telnet' or 'slow
>>network' in this news group and find lots of this.
>I think the TA for this would be "SCO....Fix this problem!!!!!!!"
>This does not happen on any version of Linux we're running. Also,
>what's the purpose of doing such a reverse lookup if, after 2
>minutes of trying a reverse lookup and failing, you still let the
>offending party in?
>Can anyone tell me where this is a problem other than on SCO products?
Don't know whether you'd call it a problem or not, but I've seen
this same occur with other OSs.
Since it does take several seconds to perform reverse lookups in
some environments - it seems reasonable to give at least some time
for authentication to occur.
I've had the long log when I'm using an ISP which does not properly
reverse the IP's on their dialups. And none of the OSes in the
path were SCO products.
I also am not permitted an ssh to one of these through the same
ISP. However the work around on that is to run a ssh account to a
Linux system a good distance away and then run a secure sh to the
other local site.
I guess I describe it best as how the security is implement or
viewed in the particular OS.
>Geez, just fix it!
Assuming it is broken.
It seems like it's only been in the last two months where this has
become an almost daily question.
--
Bill Vermillion - bv @ wjv . com
Tony Lawrence
>
> At 04:30 PM 10/5/00 -0700, Scott Taylor wrote:
> >thu...@my-deja.com wrote:
> > >
> > > using uw7.1.1 on compaq proliant 1600.
> > > to get to the login prompt(via telnet/ftp) on one m/c on LAN takes
> > > +20secs. It is nothing to do with the n/w because other m/cs on the
> > > same LAN only takes 1-2secs. Ping gives same results as the other m/cs.
> >
> >This seems to be popping up a lot lately. Isn't there a TA for this
> >yet?
> >I believe: could be to do with your /etc/resolv.conf file, but I'm not
> >sure what you mean by an m/c or n/w or m/cs (my ignorance I guess)
> >
> >/etc/resolv.conf should have this line:
> >hostresorder local bind
> >
> >There may be more, you can search for 'slow telnet' or 'slow network' in
> >this news group and find lots of this.
> >
> >GL
> >
> >--
> >Scott Taylor
> >MIS, MAAX Westco Inc.
>
> I think the TA for this would be "SCO....Fix this problem!!!!!!!" This
> does not happen on any version of Linux we're running.
It certainly does- in fact, the same questions and the same
answers are frequently seen in Linux newsgroups.
Ken Wolff
>It seems like it's only been in the last two months where this has
>become an almost daily question.
>
>--
>Bill Vermillion - bv @ wjv . com
True. It's been there as long as I can remember but we're hearing alot
more about it now. Does that mean more folks are trying SCO?
Ken
Ken Wolff
>Ken Wolff wrote:
> >
> >
> > I think the TA for this would be "SCO....Fix this problem!!!!!!!" This
> > does not happen on any version of Linux we're running.
>
>answers are frequently seen in Linux newsgroups.
>
>
>--
>Tony Lawrence (to...@aplawrence.com)
>SCO/Linux articles, help, book reviews, tests,
>job listings and more : http://www.pcunix.com
A 2 minute delay or a few second delay? From Redhat 5.x to at least 6.1
I've not experienced this.
Ken
Tony Lawrence
>
> At 07:26 AM 10/6/2000 -0400, Tony Lawrence wrote:
> >Ken Wolff wrote:
> > >
> > >
> > > does not happen on any version of Linux we're running.
> >
> >answers are frequently seen in Linux newsgroups.
> >
> >
> >--
> >Tony Lawrence (to...@aplawrence.com)
> >SCO/Linux articles, help, book reviews, tests,
> >job listings and more : http://www.pcunix.com
>
> A 2 minute delay or a few second delay? From Redhat 5.x to at least 6.1
> I've not experienced this.
Well see, that's a design issue. It's like people faulting
Kermit file transfers for being slow out of the box when that's a
deliberate design choice for reliability (and can, of course, be
changed).
SCO tends to think in terms of larger systems, and their code
often shows that. You are correct that linux systems have a
shorter timeout, but that also means that Linux sysyems will NOT
correctly identify hosts that a SCO system will.
So what's the right choice- the too short Linux way or the too
long SCO way? It depends on your environment- small, closely
connected networks would like Linux's default, larger, less well
connected networks might be better with SCO's approach.
Bill Vermillion
>> At 07:26 AM 10/6/2000 -0400, Tony Lawrence wrote:
>> >Ken Wolff wrote:
>> > > I think the TA for this would be "SCO....Fix this
>> > > problem!!!!!!!" This does not happen on any version of Linux
>> > > we're running.
>> >It certainly does- in fact, the same questions and the same
>> >answers are frequently seen in Linux newsgroups.
>> A 2 minute delay or a few second delay? From Redhat 5.x to at
>> least 6.1 I've not experienced this.
>SCO tends to think in terms of larger systems, and their code
>often shows that. You are correct that linux systems have a
>shorter timeout, but that also means that Linux sysyems will NOT
>correctly identify hosts that a SCO system will.
>So what's the right choice- the too short Linux way or the too
>long SCO way? It depends on your environment- small, closely
>connected networks would like Linux's default, larger, less well
>connected networks might be better with SCO's approach.
And it's not a problem when the networks are properly set up.
Ken Wolff
>And it's not a problem when the networks are properly set up.
>
>--
>Bill Vermillion - bv @ wjv . com
Except when your using DNS and your internet connection goes down. Despite
having all local IPs in /etc/hosts and having "hostresorder local bind" in
/etc/resolv.conf, once we loose our internet connection we run into the delay.
Ken
Brian K. White
then you either have to run your own dns, or set something up that monitors
the net connection and removes "nemeserver x.x.x.x" from /etc/resolv.conf
whenever the net connection is down.
I had to do this so that vsi-fax would keep working. It's commands time-out
in a few seconds, and gives up before the resolver deigns to respond. 1/2
hour call with vsi-fax uncovered this when a working installation stopped
working.
I agree, the timeout should be adjustable (like kermits
robustness-vs-performance settings) and if /etc/resolv.conf says "host
resorder local bind" and you have populated /etc/hosts then dammit the
resolver should try the hosts file first and not go any further if it finds
an answer in there.
--
Brian K. White http://www.squonk.net/users/linut
+++++[>+++[>+++++>+++++++<<-]<-]>>+.>.+++++.+++++++.-.[>+<---]>++.
filePro BBx Linux SCO Prosper/FACTS AutoCAD #callahans Satriani
Ken Wolff
>I agree, the timeout should be adjustable (like kermits
>robustness-vs-performance settings) and if /etc/resolv.conf says "host
>resorder local bind" and you have populated /etc/hosts then dammit the
>resolver should try the hosts file first and not go any further if it finds
>an answer in there.
>
>--
>Brian K. White http://www.squonk.net/users/linut
>+++++[>+++[>+++++>+++++++<<-]<-]>>+.>.+++++.+++++++.-.[>+<---]>++.
>filePro BBx Linux SCO Prosper/FACTS AutoCAD #callahans Satriani
Yes. One would think that if you specify "hostresorder local bind" and the
IP is found in /etc/hosts, why then check DNS. Just from my experience all
I can figure is this is JUST the search order. So in this case it does
check /etc/hosts but then also checks DNS even if the IP is found in
/etc/hosts.
That's what I'm referring to as a "fix". Search these sources in this
order, but as soon as you've resolved the address, stop searching.
Ken
Tony Lawrence
>
> At 07:26 AM 10/6/2000 -0400, Tony Lawrence wrote:
> >Ken Wolff wrote:
> > >
> > >
> > > does not happen on any version of Linux we're running.
> >
> >answers are frequently seen in Linux newsgroups.
> >
> >
> >Tony Lawrence (to...@aplawrence.com)
> >SCO/Linux articles, help, book reviews, tests,
> >job listings and more : http://www.pcunix.com
>
> I've not experienced this.
Just for the heck of it, I removed all other machine's IP
addresses from a Corel box here and tried telnets and ftp's to
it. *Most* of the time the delay was not long enough to cause
any problem, but 3 times out of 10, telnet or ftp would fail and
give up. That's on a local lan.. same problem, same solution.
Jim Bonnet
>
> thu...@my-deja.com wrote:
> >
> > using uw7.1.1 on compaq proliant 1600.
> > to get to the login prompt(via telnet/ftp) on one m/c on LAN takes
> > +20secs. It is nothing to do with the n/w because other m/cs on the
> > same LAN only takes 1-2secs. Ping gives same results as the other m/cs.
>
> This seems to be popping up a lot lately. Isn't there a TA for this
> yet?
> I believe: could be to do with your /etc/resolv.conf file, but I'm not
> sure what you mean by an m/c or n/w or m/cs (my ignorance I guess)
>
> /etc/resolv.conf should have this line:
> hostresorder local bind
Unixware doesnt use the hostresorder line, use scoadmin, networking,
client manager instead.
>
> There may be more, you can search for 'slow telnet' or 'slow network' in
> this news group and find lots of this.
>
> GL
>
> --
> Scott Taylor
> MIS, MAAX Westco Inc.
--
Jim Bonnet
Technical Support Engineer
The Santa Cruz Operation
Ken Wolff
>Just for the heck of it, I removed all other machine's IP
>addresses from a Corel box here and tried telnets and ftp's to
>it. *Most* of the time the delay was not long enough to cause
>any problem, but 3 times out of 10, telnet or ftp would fail and
>give up. That's on a local lan.. same problem, same solution.
>
>
>--
>Tony Lawrence (to...@aplawrence.com)
>SCO/Linux articles, help, book reviews, tests,
>job listings and more : http://www.pcunix.com
Correct. I'm aware of that. What I've always complained about regarding
this problem is that:
- If the IP of the remote machine is in /etc/hosts...... and
- If resolv.conf contains "hostresorder local bind"..... and
- If your internet connection goes down (no DNS)....
= you get a delay.
To quote 'man resolv.conf'
For example, the following line specifies a lookup order of NIS,
DNS, and finally the /etc/hosts file. All databases will be tried
until a match is found.
hostresorder nis bind local
...wrong. All databases will be tried even if matches are found. Or at
least that seems to be the situation.
Ken
Bill Vermillion
>>And it's not a problem when the networks are properly set up.
>Except when your using DNS and your internet connection goes down.
>Despite having all local IPs in /etc/hosts and having "hostresorder
>local bind" in /etc/resolv.conf, once we loose our internet
>connection we run into the delay.
I still say 'when the networks are properly set up'.
If your internet connection goes down and you won't be able to get
to external sites.
So I'm assuming you are having local problems. Go back and read the
fixes. If you have windows machines make sure they all have the
entries in them.
Or better yet, run DNS locally, and have every machine point to
that. The other solutions - all machines have their own private
version of the /etc/hosts file - get's cumbersome to maintain.
DNS isn't that hard. And it's a one place solution - maintain it
on one machine and just add entries when knew machines come up.
Instead of adding ONE line to /etc/hosts, you add a line to
what is the DNS hosts equivalent AND a line to the reverse mapped
file. Editing two files to add one machine - and having everyting
work properly - is a very small price to pay.
Again - the problem is that the target machines can't resolve the
IP/name of the connecting machine. Why local machines are not seen
when your ISP goes down is a strange scenario in my way of looking
at networks.
Since most of the machines I work on are net connected, I prefer
the really secure approach, and if you can't be resolved you are
ignored. The argument that Linux lets you in immediately won't
work for me - I'm the type that keeps my doors locked when I'm
inside too.
Bill
Bill Vermillion
>>Just for the heck of it, I removed all other machine's IP
>>addresses from a Corel box here and tried telnets and ftp's to
>>it. *Most* of the time the delay was not long enough to cause
>>any problem, but 3 times out of 10, telnet or ftp would fail and
>>give up. That's on a local lan.. same problem, same solution.
>Correct. I'm aware of that. What I've always complained about
>regarding this problem is that:
>- If the IP of the remote machine is in /etc/hosts...... and
>- If resolv.conf contains "hostresorder local bind"..... and
>- If your internet connection goes down (no DNS)....
>= you get a delay.
>
>To quote 'man resolv.conf'
> For example, the following line specifies a lookup
> order of NIS, DNS, and finally the /etc/hosts file. All
> databases will be tried until a match is found.
> hostresorder nis bind local
>...wrong. All databases will be tried even if matches are found. Or
>at least that seems to be the situation.
The problem is the machine you are trying to connect TO need to
look up the entry, and the target machine has no clue as to
/etc/hosts on the Unix side. I'm also assuming that your
target machine uses DNS using the ISP's DNS so that it will time
out trying to find that information.
The man is correct, the Unix system will look in the files in the
order in which you specify. hostresorder local bind witll go
to /etc/hosts and then to DNS - ON THE UNIX MACHINE - not the
targe.
Tom Parsons
| At 01:22 PM 10/6/00 -0400, Tony Lawrence wrote:
|
| >Just for the heck of it, I removed all other machine's IP
| >addresses from a Corel box here and tried telnets and ftp's to
| >it. *Most* of the time the delay was not long enough to cause
| >any problem, but 3 times out of 10, telnet or ftp would fail and
| >give up. That's on a local lan.. same problem, same solution.
| >
| >
| >Tony Lawrence (to...@aplawrence.com)
| >SCO/Linux articles, help, book reviews, tests,
| >job listings and more : http://www.pcunix.com
|
| this problem is that:
|
| - If the IP of the remote machine is in /etc/hosts...... and
| - If resolv.conf contains "hostresorder local bind"..... and
| - If your internet connection goes down (no DNS)....
| = you get a delay.
|
| To quote 'man resolv.conf'
|
| For example, the following line specifies a lookup order of NIS,
| DNS, and finally the /etc/hosts file. All databases will be tried
| until a match is found.
|
| hostresorder nis bind local
|
| ..wrong. All databases will be tried even if matches are found. Or at
| least that seems to be the situation.
Just having hostresorder bind local in /etc/resolv.conf isn't the
solution, having a properly constructed resolv.conf file is. Post your
file.
--
==========================================================================
Tom Parsons t...@tegan.com
==========================================================================
David Mabo
machine or network. That way you will always have a name server to
resolve local names. My choice would be a secondary for you local
domain.
Bill Vermillion wrote:
>
> In article <4.3.2.7.2.200010...@scogr1.cscc.maximus.com>,
> Ken Wolff <ke...@cscc.maximus.com> wrote:
> >At 01:22 PM 10/6/00 -0400, Tony Lawrence wrote:
>
> >>Just for the heck of it, I removed all other machine's IP
> >>addresses from a Corel box here and tried telnets and ftp's to
> >>it. *Most* of the time the delay was not long enough to cause
> >>any problem, but 3 times out of 10, telnet or ftp would fail and
> >>give up. That's on a local lan.. same problem, same solution.
>
> >Correct. I'm aware of that. What I've always complained about
> >regarding this problem is that:
>
> >- If the IP of the remote machine is in /etc/hosts...... and
> >- If resolv.conf contains "hostresorder local bind"..... and
> >- If your internet connection goes down (no DNS)....
> >= you get a delay.
> >
> >To quote 'man resolv.conf'
>
> > For example, the following line specifies a lookup
> > order of NIS, DNS, and finally the /etc/hosts file. All
> > databases will be tried until a match is found.
>
> > hostresorder nis bind local
>
> >...wrong. All databases will be tried even if matches are found. Or
> >at least that seems to be the situation.
>
> The problem is the machine you are trying to connect TO need to
> look up the entry, and the target machine has no clue as to
> /etc/hosts on the Unix side. I'm also assuming that your
> target machine uses DNS using the ISP's DNS so that it will time
> out trying to find that information.
>
> The man is correct, the Unix system will look in the files in the
> order in which you specify. hostresorder local bind witll go
> to /etc/hosts and then to DNS - ON THE UNIX MACHINE - not the
> targe.
>
> --
> Bill Vermillion - bv @ wjv . com
--
David H. Mabo, CPCM
Adaptix Corp. - Cincinnati, Ohio
Ken Wolff
>The problem is the machine you are trying to connect TO need to
>look up the entry, and the target machine has no clue as to
>/etc/hosts on the Unix side.
The target machine was our OpenServer box with IP entries in /etc/hosts.
> I'm also assuming that your
>target machine uses DNS using the ISP's DNS so that it will time
>out trying to find that information.
>
>The man is correct, the Unix system will look in the files in the
>order in which you specify. hostresorder local bind witll go
>to /etc/hosts and then to DNS - ON THE UNIX MACHINE - not the
>targe.
I understand the search order, but the man page states "All databases will
be tried until a match is found". That's the part I think is incorrect as
it seems to try all databases regardless if a match is found.
>--
>Bill Vermillion - bv @ wjv . com
For us the point is moot. I eventually setup DNS running on our firewall
and point the our OpenServer to that DNS server.
In the past our OpenServer box had a 24x7 (probably mroe like 23.75x7) dial
up connection to our ISP and used our ISP's DNS servers. All 15 of our
Win95 PCs were listed in /etc/hosts. resolv.conf was as follows:
domain cscc.maximus.com
hostresorder local bind
search cscc.maximus.com
nameserver 204.177.184.10
nameserver 204.177.184.15
Our OpenServer IP address was in \windows\hosts on each of the Win95 PCs.
Whenever our dialup connection to our ISP (and their DNS servers) went down
we encountered the login delay despite the fact ALL boxes in our building
were listed in /etc/hosts. Once the dial up connection was reestablished
(usually within a minute or two) everything was fine.
I understand that I could have fixed this by running local DNS on the
OpenServer box. However, with 1 Openserver box and 15 Win95 boxes I though
DNS was just a bit of overkill when /etc/hosts should work. That's why
I've always looked at this as something that needed "fixing".
(Sorry, originally posted directly back to Bill and forgot to change
'distribution' to 'scomsc').
Ken
Bill Vermillion
>>The problem is the machine you are trying to connect TO need to
>>look up the entry, and the target machine has no clue as to
>>/etc/hosts on the Unix side.
>The target machine was our OpenServer box with IP entries in
>/etc/hosts.
This thread has gone so long I was thinking it was the SCO system
trying to connect to other. Sorry about that.
>> I'm also assuming that your
>>target machine uses DNS using the ISP's DNS so that it will time
>>out trying to find that information.
>>The man is correct, the Unix system will look in the files in the
>>order in which you specify. hostresorder local bind witll go
>>to /etc/hosts and then to DNS - ON THE UNIX MACHINE - not the
>>targe.
>I understand the search order, but the man page states "All
>databases will be tried until a match is found". That's the part I
>think is incorrect as it seems to try all databases regardless if a
>match is found.
I've never seen behaviour like that.
>For us the point is moot. I eventually setup DNS running on our
>firewall and point the our OpenServer to that DNS server.
That's a good solution.
>In the past our OpenServer box had a 24x7 (probably mroe like
>23.75x7) dial up connection to our ISP and used our ISP's DNS
>servers. All 15 of our Win95 PCs were listed in /etc/hosts.
>resolv.conf was as follows:
>domain cscc.maximus.com
>hostresorder local bind
>search cscc.maximus.com
>nameserver 204.177.184.10
>nameserver 204.177.184.15
>Our OpenServer IP address was in \windows\hosts on each of the
>Win95 PCs.
That was not clear from before, but the slow login to the SCO is
because for some reason the SCO system isn't seeing the Win machine
in it's hosts file. Since you've got it fixed there is no way to
tell, but I wonder if the Win machines had become confused.
Running winipcfg will let you know what the Win machine thinks it
has in way of addresses, gateways, etc.
>Whenever our dialup connection to our ISP (and their DNS servers)
>went down we encountered the login delay despite the fact ALL
>boxes in our building were listed in /etc/hosts. Once the dial
>up connection was reestablished (usually within a minute or two)
>everything was fine.
It almost seems the order was reversed - such as looking at the ISP
first. It delayed trying to connect to the ISP until it timed out,
then just gave the login. What is intereting is that the
SCO system is either 1) not recognizing something legitimate in
/etc/hosts, or 2) for some reason the Win machine is not
transmitting the correct information.
>I understand that I could have fixed this by running local DNS on
>the OpenServer box. However, with 1 Openserver box and 15 Win95
>boxes I though DNS was just a bit of overkill when /etc/hosts
>should work. That's why I've always looked at this as something
>that needed "fixing".
I use a Unix system as a gateway on a dial-up and run DNS on that
so that I cache often used outside addresses.
>(Sorry, originally posted directly back to Bill and forgot to change
>'distribution' to 'scomsc').
I got the mail - and I decided I'd check here before replying
directly. Based on what I've seen with Win machines connecting to
a network my first thought would be it's a problem on the Win side.
Up to about 9 months ago I was working a lot with a large dynamic
network - dynamic meaning it changed weekly not related to DHCP.
In a two day period 200-500 machines could be brought up for a
convention - and I saw more than my share of IP problems. :-(
Win9X machines were the worst. Some NT problems. Once you learned
the quirks of the Apple systems they were OK. But then someone
would bring in some 'interesting' equipment for sub-networks and
not all communicated transparently with the default modes the
manufacturers set up.
Glad it's working for you now.
Ken Wolff
>That was not clear from before, but the slow login to the SCO is
>because for some reason the SCO system isn't seeing the Win machine
>in it's hosts file. Since you've got it fixed there is no way to
>tell, but I wonder if the Win machines had become confused.
>Running winipcfg will let you know what the Win machine thinks it
>has in way of addresses, gateways, etc.
But if I changed hosresorder to just local, the SCO box saw these PCs just
fine. Anytime we knew our dial up would be down for an extended period I
just removed bind from hostresorder. Thinking back now, I believe I could
have just kept it that way since a)all IPs are in /etc/hosts and b) no
machine except internal machines were allowed in.
>--
>Bill Vermillion - bv @ wjv . com
--------------------------------------------------------------
Ken Wolff
Phone: 616-957-4949 Ext: 111
FAX: 616-957-1614
--------------------------------------------------------------
Bill Vermillion
>>That was not clear from before, but the slow login to the SCO is
>>because for some reason the SCO system isn't seeing the Win machine
>>in it's hosts file. Since you've got it fixed there is no way to
>>tell, but I wonder if the Win machines had become confused.
>>Running winipcfg will let you know what the Win machine thinks it
>>has in way of addresses, gateways, etc.
>But if I changed hosresorder to just local, the SCO box saw these
>PCs just fine. Anytime we knew our dial up would be down for an
>extended period I just removed bind from hostresorder. Thinking
>back now, I believe I could have just kept it that way since a)all
>IPs are in /etc/hosts and b) no machine except internal machines
>were allowed in.
And the only thing you had in there before was
hostresorder local bind
in that order ?
'tis strange. So why does your dial up go down 'for extended
periods'. Need is ask :-)
Locally a group of dis-satisfied customers banded together and
are building their own ISP - so they can 'control their own
destiny'. Finding reliable providers with good support can be a
bit trying at times, they finally gave up to do it themselves.
Bill
Ken Wolff
>And the only thing you had in there before was
>
>hostresorder local bind
>
>in that order ?
Yep, in addition to the 'search' and 'nameserver' statements. Hey I still
run into the same problem today if our internal DNS server is down. But at
least I can schedule that (in most circumstances). Our SCO box points to
our internal Linux DNS firewall for DNS, but if it's not up, boom, delay in
login.
>'tis strange. So why does your dial up go down 'for extended
>periods'. Need is ask :-)
Again, it's been at least a year since we dumped dial up in favor of Fract
T1, but there were various problems. At one time their accounting dept
decided that since we cancelled (ie did not renew) 2 other obsolete domain
names, we also wanted this canceled. But even though their accounting dept
could turn our account off, they could not turn it back on.
Another time our ISP had an entire bank of dialups go down for 2 days, of
which we were one. Just another reason we went to a dedicated connection.
Just goes to show there ain't such thing as a "dedicated dial up".
>Locally a group of dis-satisfied customers banded together and
>are building their own ISP - so they can 'control their own
>destiny'. Finding reliable providers with good support can be a
>bit trying at times, they finally gave up to do it themselves.
>
>
>Bill
>--
>Bill Vermillion - bv @ wjv . com