🚀 go-pugleaf

Keywords: server  client
Distribution: world

UNIX GURU's. OPINIONS NEEDED ON ONE POINT!!! PLEASE SCAN BEFORE IGNORING.

I have a VERY simple non-Netboot solution to client/server lookalike  
problem, but I'm afraid it may cause system corruption. Guru's skip to   
paragraph labeled "QUESTION" below. The rest of this is a step-by-step  
outline of the whole server/client setup process.

---------------------------------------------------------
Well I got a lot of advice on how to make client filesystems identical to  
their server's. I learned the following that I think is worth sharing  
(assumes the standard Netinfo server/client arrangement):

1. Backup all relevant files (of course). Attach cd-rom drive directly to  
each machine in turn. Use complete install option of NS 3.0 installer  
(init disk) for both server and clients. Install base OS ~70MB. It is not  
necessary to partition the server's disk into read only and read/write  
export sections (because I'm going to export root and keep everything  
under root on the server on a 1GB drive). Use HostManager Local option for  
each client to set them up on the network. Make then Netinfo clients. Add  
/etc/resolv.conf file for domain name server (if any). Adjust client's  
sendmail to use server's name in their From: field. That's it for the  
clients. All other work is done on the server.

2. Set up network accounts (at root domain level), but make their home  
directories be /Users/person instead of /Net/server/Users/person (This  
avoids the automounting associated with /Net. I tested it. The /Net  
approach appeared to have about 3 times slower access times than a hard  
mount ALL THE TIME. Does this make sense?) Restore account data from  
backups as needed.

3. Set up server as mail server.

4. Export root as read/write from the server to each of the clients. NFS  
Manager is great for doing this although you've got to double-click the  
return button to get "/" to register. Each client gets root access.

5. At Netinfo root domain level in NFS Manager set up the following  
imports (another great use of NFS Manager):

server:/bin /bin                                    ro
server:/lib /lib                                    ro
server:/usr /usr                                    ro
server:/LocalApps /LocalApps                        ro
server:/LocalLibrary /LocalLibrary                  ro
server:/NextApps /NextApps                          ro
server:/NextDeveloper /NextDeveloper                ro         
server:/NextLibrary /NextLibrary                    ro
server:/private/spool/mail /private/spool/mail      rw
server:/Users /Users                                rw

{One person suggested that /LocalApps and /LocalLibrary may need to be  
mounted rw. So far no problem. When it is a problem, I'll change the  
mount. It's trivial with NFS Manager. (If you haven't guessed by now, I  
REALLY like NFS Manager.)}

All of the above mounts will be done on each Netinfo child of the root  
domain at boot time. The mounter is smart enough to not mount to the  
server even though it's a child of the root domain also. Messages appear  
saying something like "server:/bin /bin  Not done because /bin is already  
local to server"

The interesting thing I learned is that these mounts simply "override" the  
existing directories on the clients without disturbing the existing  
contents. Thus the existing contents are used at boot time and then simply  
disappear to be replaced by the server's directories after booting is  
completed. I never knew that mounting could work this way. It's not in the  
Sys Admin Manual that's for sure.
-----------------------------------------------------------------
QUESTION: This seems to work great except I worry about things like page  
faulting on processes that were started at boot time (for example  
/usr/etc/netinfod) from the client's directories which now point to the  
server due to "overmounting". I'm worried about mixed up inodes or  
something. However, no apparent problems so far of any kind (we're been  
running this way for 3 days). Any comments from the guru's? Have I  
committed an unspeakable sin? Read on for more detailed analysis...
------------------------------------------------------------------

You might wonder why I would export directories like /bin, /lib, and /usr.  
Well that's because typical software loaded on the server put things in  
these directories. In fact I chose all the above directories as import  
candidates by looking at the log file list from the package Installer for  
the following packages:

Abbrv       Full Name
-------     --------------------------------------------
Imp         Improv
Exe         Executor
Drw         Draw
Frm         Framemaker
CoX         CoXist
F77         Absoft Fortran 77
Dan         Data Analyzer Plotting
Dgm         Diagram
Dem         NextStep 3.0 Demonstartions
Dev         NextStep 3.0 Developer
DgW         NextStep 3.0 DigitalWebster
Doc         NextStep 3.0 Documentation
Lit         NextStep 3.0 Literature
Tex         NextStep 3.0 NeXTTeX
ApT         NextStep 3.0 NeXT_AppleTalk
Syb         NextStep 3.0 Sybase_DB-Library

Here is where they installed themselves on the server (and this is before  
running any command-line install scripts like Tex has):

                                                  Packages Writing to Dir
Directory (Dir)                                   or Somewhere Below Dir
--------------------------------------------      -----------------------
/LocalApps                                          Imp, Exe, Drw, Frm,
                                                    CoX, F77, Dan, Dgm

/NextDeveloper                                      Tex, Dev, Dem

/NextLibrary                                        DgW, ApT, Doc, Lit,
                                                    Tex, Dev, Syb

/NextApps                                           DgW, Lit

/LocalLibrary                                       Tex

/bin                                                Tex, Dev

/lib                                                Dev

/private/tftpboot/boot.cdrom, diagnostics, mach     Dev

/usr/bin                                            Dev
/usr/dict                                           Dev
/usr/etc                                            ApT
/usr/netware                                        Dev
/usr/pub                                            Dev
/usr/template/client/tftpboot                       Dev
/usr/sybase                                         Syb
/usr/ucb                                            Dev
/usr/tex                                            Tex
/usr/include --> /NextDeveloper/Headers             Dev
/usr/man --> /NextLibrary/Documentation/ManPages    CoX, F77, Dev
/usr/lib                                            ApT, Doc, Dev, Syb,
                                                    CoX


COMMENTS:

Now the problem comes in that the boot scripts look for boot modules in  
/bin, /usr/bin, /usr/etc, and (where else?).  How about /private/tftpboot?  
Is it used at boot-time? I suspect so. That's why I haven't imported it  
yet (see import table above). I suspect the additions made to  
/private/tftpboot by the Developer package must be present at boot time.  
If so, can I just copy them to the clients? (Why are these files  
boot.cdrom, diagnostics, and mach added by the Developer package anyway?)

These packages make huge changes to all the above-mentioned boot target  
directories. Is this a mess or what? I sure don't care to sift out  
installed files from these directories (and make copies of them on the  
clients) each time I install a package.

Why isn't all boot code isolated to /private or /etc anyway? For example  
mach_init is in /etc as a LINK to /usr/etc/mach_init (where mach_init  
really is). Since packages come along and modify /usr, the server should  
serve /usr to its clients. But this means overmounting boot-time things  
like /usr/etc/mach_init.

Please tell me I'm worrying about nothing....If so, the above importing  
solution is quick, simple, and thorough.

-----------------------------------------------------------------
Greg Colello
Carnegie Institution, Department of Plant Biology
Stanford University
gcolello@biosphere.stanford.edu