NetNews Usenet Archive 1992 #26/NN_1992_26.iso/spool/comp/sys/next/sysadmin/6425

Text File | 1992-11-11 | 6.4 KB | 169 lines

Newsgroups: comp.sys.next.sysadmin
Path: sparky!uunet!zaphod.mps.ohio-state.edu!menudo.uh.edu!usenet
From: [e-mail] (Paul S. Sears)
Subject: Re: Making a Client's File System Look Like its Server's
Message-ID: <[e-mail]>
Sender: [e-mail] (USENET News System)
Nntp-Posting-Host: thanatos.egr.uh.edu
Reply-To: [e-mail]
Organization: University of Houston
References: <[e-mail]>
Date: Wed, 11 Nov 1992 15:20:52 GMT
Lines: 155

In article <[e-mail]>
[e-mail] (Greg Colello) writes:
=>I am trying to figure out how to make it possible for a user to do
=>anything on a client that the user could do on the client's server.
=>
=>My solution:
=>
=>0. Setup the clients and server as a Netinfo database.

Good.

=>1. Make all accounts network accounts (I acquiesed to the /Net and /Users
=>idiom of Next).

Good.

=>2. Load the base 60MB NS3.0 OS on each client.

Actually, the base NS3.0 is ~73M (77 with English Help)

=>3. Load all Next packages on the server.

Like the extended release stuff (NextDeveloper, Documentation, all the other
languages?)

=>4. Load all third party apps on the server into /LocalApps.

Bueno.

=>5. Export the following from the server as ReadOnly using the 3.0 NFS App
=>(these are the directories affected by steps 3 and 4 above):
=>
=>/LocalLibrary
=>/usr
=>/Users
=>/NextDeveloper
=>/bin
=>/lib
=>/NextLibrary
=>/NextApps
=>/LocalApps

Not so good (personal opinion, based on experience with a multi server
environment...) see below

=>6. Import each of the above on the clients using the 3.0 NFS App. Mount
=>them to /Net/server/... on the clients.

same as above (5, 6 & 7 are directly related).  See below...

=>7. Replace the step 5 directories on the clients with soft links to their
=>corresponding /Net/server/... step 6 mounts.

same as above (5, 6 & 7 are directly related).  See below...

=>8. Make the server the mail server.

Good.  export /usr/spool/mail.  Make sure sticky bit is set.  Chmod 1777
/usr/spool/mail.

=>9. Make each client a mail client of the server.

import /usr/spool/mail on each client...

(i.e., mailhost:/usr/spool/mail)

=>10. Adjust the clients' sendmail.sharedsubsidiary.cf file to cause mail
=>sent from them to bear the server's name instead of their own.

Good idea, and I would like to know what you did to make this work.  I have
been yet unsuccessful in hiding the hostnames of our clients..

=>11. Adjust our campus domain name server to send mail addressed to any of
=>the clients to the host instead. Adjust the server's sendmail.mailhost.cf
=>file to have alias' for each of the clients so the host does not reject
=>the redirected mail.

Sure, have all the clients MX to the mailhost.  Easy enough.. but if you had
successfully masked the clients anyway, then everyone would think that mail
originates only on the mailhost....

=>My first question is how many of the step 5 directories need Read/Write
=>access? For example I know that /usr/spool/mail-->/private/spool/mail
=>needs to be writable by the clients. So maybe I need to export
=>/private/spool/mail and liberalize the permissions of that path. Also for
=>example does /NextDeveloper need Read/Write access if you're doing
=>NextStep development?
=>

Depends on how you do it.  None technically need rw access (except for /Users,
which is a different case altogether).  All can be happily mounted ro (we
mount the / partition as ro...)

=>I also know that /usr/lib/sendmail is different on the clients than the
=>server. How many other such inconsistancies are there?

No.  sendmail is the same. sendmail.cf is what is different (located in
/etc/sendmail)

=>Also our server is a monochrome Cube and our clients are both mono and
=>color slabs. Are there some different OS file requirements here?

Nope... We have to mono servers (one a cube and one a slab).  We server all
kinds of configs... no problems... no special accommodations...

=>If this overall problem can be resolved it would be really neat, because
=>we could work on our server or clients completely transparently, and all
=>upgrades could be confined to the server.
=>

That is what we do here...

=>Greg Colello
=>Carnegie Institution, Department of Plant Biology
=>Stanford University
=>[e-mail]

From experience, it is far easier to manage single mount points than multiple
mount points.  Instead of exporting individual directories from the server,
export the / level, then on the clients mount the server:/ as a single mount
point, in our case we use /NeXTMount and /NeXTMount2 (we have two servers).
Then make all your links to /NeXTMount (i.e, ln -s /NeXTMount/NextDeveloper
/NextDeveloper on the client side).  We have also found that the mounts should
be _hard_ mounts.  Having things in /Net via automounter proved to be way too
unreliable when the server gets bogged down with NFS requests.  Also, in your
/etc/rc, up the # of nfsd processes from 6 to at least 8.

It is a hell of alot easier keeping information for one mount point in NetInfo
up to date and accurate than trying to keep 10-15 mounts in /Net.  From an
administration standpoint, the less mount points, the better...

And to address a particular misconception:

=>BTW we didn't use NetBoot, because each client has a good sized hard drive
=>that can be used as a local swap disk. I understood that there was no way
=>to have local swap disks with NetBooting.
=>

This is not correct.  You can have the local disk as the swap disk _if_ you
re-label the disk to be called "swapdisk."  You are making the right decision
for the wrong reasons.  NetBoot clients are a _severe_ drain on a server's
resources.  Try to avoid NetBoot clients if possible.  We have 11 (cubes with
40M accelerator drives) out of 50 clients that are net boot.  They are mostly
serviced by our secondary server which has mucho process cycles to burn, but
even that server has its performance degraded when the netboots are in heavy
use...


--
Paul S. Sears                *  [e-mail] (NeXT Mail OK)
The University of Houston    *  [e-mail] (NeXT
Engineering Computing Center *  comments, complaints, questions)
NeXT System Administration   *  DoD#1967 '83 NightHawk 650SC
          >>> SSI Diving Certification #755020059 <<<
"Programming is like sex: One mistake and you support it a lifetime."