Since all of the responses were very informative, I have included them in
whole at the end.
Thanks to the following people:
cpl1@hades.uchicago.edu (Corey Liss)
jlu@cs.umr.edu
Kenton C. Phillips <kenton@space.mit.edu>
jim@pasteur.hsf.uab.edu (Jim Hill)
Kent TSE <kent@mnementh.cs.mcgill.ca>
Mike Raffety <mike_raffety@il.us.swissbank.com>
raoul@MIT.EDU
Original posting:
# For all you sites that have a 'significant' number of NeXTs that have to
# be incorporated into a network with other Unix boxes, I would like to
# know the following:
#
# o Do you run NIS on the NeXTs?
# o If so, are there any caveats that I need to be aware of?
#
# o Do you run Netinfo on the NeXTs?
# o If so, do you 'upload' NIS info into Netinfo? Or do you
# 'download' Netinfo info into NIS? (Of course this assumes
# that you are running NIS on non-NeXT machines.)
# o If doing the above, do you have scripts that you use to
# automate this procedure?
#
# o Do you run Netinfo (Xedoc's) on the non-NeXT machines?
#
# o Other?
--------------------------------------------------------------------------
From: cpl1@hades.uchicago.edu (Corey Liss)
> o Do you run NIS on the NeXTs?
> o If so, are there any caveats that I need to be aware of?
We ran NIS on a small cluster (16 machines) of NeXTs here for a while...
The only problem was that, for some idiotic reason, the NeXT uid address
space can only handle 32000 (well, 32xyz, I don't recall the exact number)
users, while Sun's can take up 64000; we had some trouble on that front,
which we solved by purging the the user database of everyone we could...
fortunately we were near the breakline, so we didn't have to purge too
many.
> o Do you run Netinfo on the NeXTs?
> o If so, do you 'upload' NIS info into Netinfo? Or do you
> 'download' Netinfo info into NIS? (Of course this assumes
> that you are running NIS on non-NeXT machines.)
> o If doing the above, do you have scripts that you use to
> automate this procedure?
If you're running NeXTStep 3.x, then NIS is already integrated with NetInfo
in a weird sort of way... You can't use all the neatokeen NetInfo GUI
utilities on it, but if you specify NIS-active and provide an NIS domain
name when you initialize the NetInfo network on each machine, they'll
subscribe to NIS.
> o Do you run Netinfo (Xedoc's) on the non-NeXT machines?
Our setup was:
Sun NIS master server providing passwords to 3 Suns (not sure of their
setup, I was on the NeXT end of things) and 1 NeXT slave server.
The NeXT slave server acted as NIS master and NetInfo master for 15 NeXT
clients.
Apart from the address space problem, I don't recall that there were any
difficulties in particular. Of course, in terms of total number of
machines, this was a pretty small setup; if you're talking hundreds of
machines, there might be trouble.
> o Other?
The order of lookup for the NeXT clients:
-- local NetInfo passwd database
-- network NetInfo passwd database
-- NIS.
Each NeXT *WILL* be running NetInfo for its local operation. There's no
way around this. And there are, therefore, hiccups. You have to watch out
for uid conflicts between NetInfo and NIS, especially, although that's
actually easily avoided if there aren't many users on the NetInfo level.
The hybrid gets annoying, though -- all the NetInfo administration *has* to
be done through the GUI, except for that which *can't* be done through the
GUI; all the NIS administration *has* to be done on the command line. I
definitely recommend using the NIS --> NetInfo master method; getting the
initial database build on a given machine is often teeth-grittingly
annoying, but if you're using the NetInfo intermediary, you only need to
do it on one machine (instead of trying to build over and over on n
machines). The big problem *we* had was that home directories on the NeXTs
were to be different from home directories on the Suns, so we had to
develop a chain of symbolic links and ugly first-login-scripts and programs
to handle directory creation, if we didn't want to do them all by hand.
The NIS build was trivial by comparison.
Good luck...
--Corey
cpl1@hades.uchicago.edu
--------------------------------------------------------------------------
From: jlu@cs.umr.edu
I don't know how much help I can provide.
> Hi all,
> For all you sites that have a 'significant' number of NeXTs that have to
> be incorporated into a network with other Unix boxes, I would like to
> know the following:
> o Do you run NIS on the NeXTs?
Yes.
> o If so, are there any caveats that I need to be aware of?
As far as I know, NIS on the NeXT is quite stable.
>
> o Do you run Netinfo on the NeXTs?
Yes.
> o If so, do you 'upload' NIS info into Netinfo? Or do you
> 'download' Netinfo info into NIS? (Of course this assumes
> that you are running NIS on non-NeXT machines.)
Basically, we only use passwd, group, and hosts parts of NIS.
We kinda keep Netinfo and NIS in synch, except for passwd and
group.
> o If doing the above, do you have scripts that you use to
> automate this procedure?
Like above, we don't keep passwd on netinfo. So, the maintainance
among them is not too difficult.
> o Do you run Netinfo (Xedoc's) on the non-NeXT machines?
NO.
> o Other?
If you're beginner, remember to keep a copy of netinfo database
(or files) before you make changes. We had once ran into
a situation of corrupted netinfo database. But netinfo utils
cannot detect that. It just bombed itself once in a while
which is really painful.
I was told NeXTStep 3.2 is more robust than the version (2.1)
we have now. Hopefully, we'll upgrade to 3.2 sometimes this
summer. In a word, if you have a choice, do NOT use NeXTs.
(especially those black boxes.)
--Eric
> Thanks a lot. I will be summarizing.
> Andy
> --
> Andy Kumeda Trident Data Systems [ PGP Key
> E-mail: kumeda@tds.com 5933 West Century Blvd Available
> Voice: (310) 348-6327 Suite 700 Upon
> FAX: (310) 649-5437 Los Angeles, CA 90045 Request ]
-- ***************************************--- Grad. student ---* * Obviousness is always the enemy of * \ Jui-Lin Lu (Eric) / * * correctness. -- Bertrand Russell * / jlu@cs.umr.edu \ * ***************************************--- Univ. of Missouri-Rolla ---*-------------------------------------------------------------------------- From: Kenton C. Phillips <kenton@space.mit.edu>
> For all you sites that have a 'significant' number of NeXTs that have to > be incorporated into a network with other Unix boxes, I would like to > know the following:
We have about two dozen NeXTstations (68040 systems) on our network, and about sixty sparcstations. Also some Sun 3's and Decstations. The NIS master is a SunOS 4.1.3 system (as are all the slave servers).
> o Do you run NIS on the NeXTs?
Yes.
> o If so, are there any caveats that I need to be aware of?
For the most part it works fine.
> o Do you run Netinfo on the NeXTs?
They run as "non-NetInfo" systems. Which, of course, means that they are still running netinfo. So you're still stuck fighting with netinfo whenever you want to do anything like update the printcap database.
I hate netinfo.
> o If so, do you 'upload' NIS info into Netinfo? Or do you > 'download' Netinfo info into NIS? (Of course this assumes > that you are running NIS on non-NeXT machines.)
Well, when you want to do something like update /etc/hosts, netinfo gets in the way, so you have to do `niload hosts </etc/hosts`. Of course, you can skip this step and let everything come from NIS, but there are occasions where you want the information locally.
> o If doing the above, do you have scripts that you use to > automate this procedure?
I have scripts which update /etc/hosts on all machines (usefule for such occasions as diskless booting over the net). The NeXTs have to be treated as a special case, where I copy /etc/hosts over and then do an niload.
> o Do you run Netinfo (Xedoc's) on the non-NeXT machines?
Gag, why would I want to screw up my network like that? 8-)
> o Other?
The worst is printers (not that they have anything to do with NIS). First, you have to pull the niload trick to get the printcap information loaded. Then there's the fact that you can't "delete an object with children", so once a printer is defined it cannot easily be removed, although it can be modified.
Since NeXTs assume that all printers in the universe are 400dpi, a print job submitted from a NeXT to a LaserWriter attached to a Sun will bomb, which will be an e-mail message from DAEMON containing a "Job could not be printed" error. Due to a bizarre bug in the Sun spooler, this message will go, not to the originator of the job, but to postmaster. Further, there will be no clue as to who submitted the print job. *Very* annoying, since the user resubmits the job three or four times before giving up. The solution to this is for the user to define a NeXT global variable specifying a 300dpi printer resolution. (I don't remember how to do this off-hand.) Another solution is to force NeXT users to print to NeXT printers only.
Printcap entries normally look like this:
lp1|alias1|Comment to describe printer:\ ...rest of definition...
NeXTs don't like the spaces in the "Comment" field, and they use the beginning of that field to display in the print tool. All of which means that you need to be careful how you choose and format your list of printer names.
Finally, the lpr/lpq/lprm commands on the NeXT ignore $PRINTER if you've ever selected a printer with the NeXT print manager. (Maybe this has changed. I haven't checked it since NeXTstep 2.0 or so).
Kenton C. Phillips Computer Systems Manager MIT Center for Space Research kenton@space.mit.edu
-------------------------------------------------------------------------- From: jim@pasteur.hsf.uab.edu (Jim Hill)
Xedoc's netinfo for Solaris is not yet available. We are planning on running netinfo on our solaris machines.
--- ************************************************************ * Jim F. Hill | * * 301 S. 20th St., Ste 201 | The real measure of our * * Birmingham, AL 35233 | wealth is how much we'd * * USA | be worth if we lost all * * Tel: (205)731-9670 | our money. *
* Fax: (205)731-9856 | * * Internet: jim@hsf.uab.edu | -John Henry Jowett- * ************************************************************
--------------------------------------------------------------------------
From: Kent TSE <kent@mnementh.cs.mcgill.ca>
In article <9404270259.AA07518@sparky.tds.com> you write: >Hi all,
>For all you sites that have a 'significant' number of NeXTs that have to >be incorporated into a network with other Unix boxes, I would like to >know the following:
Hello,
I have about 50 NeXTs integrated in a network of 200 other workstations ranging from Suns, DECs, SGIs, IBMs, ...
> o Do you run NIS on the NeXTs?
We run it on some of them, but there are problems in their implementation, it's not complete.
> o If so, are there any caveats that I need to be aware of?
Netgroups is the biggest thing that does not work like it does on the Sun. Netgroups only work for exports and will not work with the passwd file. Once you use it for accounts you will have to give access to the machine to everyone that is in the NIS passwd file.
> o Do you run Netinfo on the NeXTs?
Yes, on most of them we do.
> o If so, do you 'upload' NIS info into Netinfo? Or do you > 'download' Netinfo info into NIS? (Of course this assumes > that you are running NIS on non-NeXT machines.)
We upload most of the information that we need into Netinfo. The easiest way to do this is to use "rsh" and "niload" and "nidump".
> o If doing the above, do you have scripts that you use to > automate this procedure?
We have some, but it's very specific to our needs.
> o Do you run Netinfo (Xedoc's) on the non-NeXT machines?
Nope, it was too expensive for our needs.
- Kent
-- Kent Tse School of Computer Science System Programmer McGill University kent@cs.mcgill.ca 3480 University Street, Room 318 (514) 398-6697 Montreal, Quebec, Canada, H3A 2A7 FAX: (514) 398-3883 SOCS Help Desk: (514) 398-7087
--------------------------------------------------------------------------
From: raoul@MIT.EDU
There is a NeXT running 2.0 on our network of Sparc's. I load network information by hand into /etc/hosts, /etc/passwd, etc., do not run NIS, and merely doublecheck after running niload that nidump gives similar information.
Nico Garcia raoul@athena.mit.edu
-- Andy Kumeda Trident Data Systems [ PGP Key E-mail: kumeda@tds.com 5933 West Century Blvd Available Voice: (310) 348-6327 Suite 700 Upon FAX: (310) 649-5437 Los Angeles, CA 90045 Request ]
This archive was generated by hypermail 2.1.2 : Fri Sep 28 2001 - 23:09:00 CDT