Re: Telnet printing
From: Jeff Liebermann (jeffl_at_comix.santa-cruz.ca.us)
Date: 02/02/04
- Next message: thegrendel_at_theriver.com: "Re: No longer supporting Unixware / Open Server"
- Previous message: Joe Dunning: "Re: No longer supporting Unixware / Open Server"
- In reply to: Joe Dunning: "Re: Telnet printing"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: Sun, 01 Feb 2004 17:48:07 -0800
On Sun, 01 Feb 2004 23:40:10 GMT, joe@blahblah.invalid (Joe Dunning)
wrote:
>>Agreed. However, there are a few things one should know before
>>blundering onward. Since a VPN router is essentially transparent to
>>all forms of traffic, I was getting clobbered by excessive broadcast
>>traffic propagated through the routers.
>This seems a little strange. Routers, don't in general pass broadcast
>traffic. The VPN tunnels I have set up don't pass broadcasts.
Correct. I wasn't very clear. If I setup the VPN to *NOT* pass
broadcast traffic (the usual default), Windoze browsing is erratic (or
fails) and centralized DHCP does't work. If I enable propagating
broadcasts, then they work, but with excessive broadcast traffic.
>This is exactly what WINS is for: to allow browsing between different
>networks.
Yep. I guess I have to justify why I didn't use WINS (Windoze
Internet Name Service). In order of importance:
1. WINS requires a server of some sorts. It also makes little sense
with a single WINS server as it was designed as a distributed (and
dynamic) NETBIOS name service which requires a replicating WINS server
at each remote office. This did not exist. The only real file server
was SCO OpenServer, which doesn't have a WINS server. I could have
installed Samba, but this was before their WINS server was working.
2. I had a perfectly functional alternative in populating a HOSTS and
LMHOSTS file, on each client, with the latest namde->IP mapping. Only
the servers and print servers needed to be added. I didn't care about
browsing the dynamic IP clients and remote access clients. The only
downside was that stupid Windoze would check LMOSTS file *LAST* and
only after failing with WINS, DNS, and name resolution via broadcasts.
If someone had WINS enabled, then name lookups would take an extra 30
seconds. I also had a handy batch file to map drives. Something
like:
net use f: \\machine01\c_drive
net use g: \\machine02\c_drive
net use h: \\machine02\share_name
If that failed because the LMHOSTS files was out of date (as was
common on lightly used laptops), I would use:
net use f: \\192.168.0.20\c_drive
net use g: \\192.168.0.21\c_drive
net use h: \\192.168.0.21\share_name
which was guaranteed to work. As long as I didn't need to browse,
share, or map a dynamically assigned IP, the batch files would work
like a charm.
3. It wasn't my decision. The application service company declared
WINS to be a loser and would not support it.
4. The local Windoze experts all suggested that if I really wanted to
play name server, I should instead setup a DNS server. I don't recall
the exact reason they failed to appreciate WINS, but I do recall that
the feeling was universal among the experts. Since they didn't need
dynamic DNS (DDNS), and there was no need to browse any machines with
dynamic IP's, methinks the static solution made the most sense.
5. They had WINS running on an old NT4SP6 server and later a W2KSP1
server, both of which had a history of having the WINS server process
fail to start ("RPC server is unavailable"), or of corrupting its
database. When someone decided to use "Norton Ghost" to setup
cookie-cutter workstations, they forgot to change the system name.
When about 6 machines appeared with the same NETBIOS name, WINS would
promptly spend all its time adding errors to the self-compacting
(self-corrupting) database logfile. It also tended to deadlock the
files requiring a reboot to recover before restoring. Auto purging
stale objects was another problem, as even manually flushing the WINS
cache, from the WINS console, would not vaporize these old entries.
Moving servers around was hell because of the stale objects.
Restoring the previously backed up database or starting over with a
blank database was a regular event. When someone decided to setup a
BDC (Backup Domain Controller) and replicated the WINS database to it,
database corruption became even more frequent. My limited experience
with WINS was not very good.
[Bringing off topic discussions to a new low...]
-- Jeff Liebermann 150 Felker St #D Santa Cruz CA 95060 (831)421-6491 pgr (831)336-2558 home http://www.LearnByDestroying.com AE6KS jeffl@comix.santa-cruz.ca.us jeffl@cruzio.com
- Next message: thegrendel_at_theriver.com: "Re: No longer supporting Unixware / Open Server"
- Previous message: Joe Dunning: "Re: No longer supporting Unixware / Open Server"
- In reply to: Joe Dunning: "Re: Telnet printing"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|
