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

Text File | 1992-11-11 | 8.5 KB | 242 lines

Newsgroups: comp.sys.next.sysadmin
Path: sparky!uunet!ukma!usenet.ins.cwru.edu!agate!stanford.edu!leland.Stanford.EDU!news
From: [e-mail] (Greg Colello)
Subject: Re: Making a Client's File System Look Like its Server's
Message-ID: <[e-mail]>
Sender: [e-mail] (Mr News)
Organization: DSO, Stanford University
References: <[e-mail]>
Date: Wed, 11 Nov 92 19:52:33 GMT
Lines: 230

Paul:

Thanks for the very detailed response to my detailed request. Below I
answer your question about how we make the mail clients "FROM:" field have
the server's address. I also have lots of questions in response to your
answers:

Greg

---------------------------------------------
In article <[e-mail]> [e-mail]
(Paul S. Sears) writes:

> =>3. Load all Next packages on the server.
>
> Like the extended release stuff (NextDeveloper, Documentation, all the
other
> languages?)

Yes.

---------------------------------------------
> =>8. Make the server the mail server.
>
> Good.  export /usr/spool/mail.  Make sure sticky bit is set.  Chmod 1777
> /usr/spool/mail.

But you're exporting / as you explain below. I thought you couldn't export
a child path if its parent was already exported (more below). What's this
about setting the sticky bit?

---------------------------------------------
> =>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..
>

At the top of the sendmail.sharedsubsidiary.cf file in each client we add
the 2 lines starting with "#appear to be..." (our server is biosphere):

# major relay mailer
DMetherl

#appear to be from biosphere
DZbiosphere

# major relay host
DRmailhost
CRmailhost

Then change line (around 215) from:

R$+            $@$1<@$w>            tack on our
hostname

to:

R$+            $@$1<@$Z>            tack on our
hostname

Which replaces "w" (self I assume) with the "Z" variable defined above.

---------------------------------------------
> =>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....
>

True enough. But just in case anyway. Actually this can occur for a while
after solving the masking problem, since people on the net sometimes still
have the erroneous address on some mail they received. They then use that
address to send mail at a much later date.

BTW in case anyone is curious how we do the "alias" trick we add the
following lines at the top of the server's (biosphere)
/etc/sendmail/sendmail.mailhost.cf file (our clients are gaia and stoma):

#create "w file" which are treated as domain name server aliases for
biosphere
Cwgaia gaia.Stanford.EDU stoma stoma.Stanford.EDU


---------------------------------------------
> =>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...)
>

Doesn't /usr/spool/mail need to be writable? I think so for users who
prefer to use Unix command line mail (we have some).

Whoa. Partition? Who said anything about a partition? We have no
partitions on our disks. Is that how you are able to export the root as
read only and yet also export children like "/usr/spool/mail" and "/Users"
as read/write?

BTW the 3.0 installer apparently doesn't give you the ability to create
partitions when you use its "complete install" mode.

---------------------------------------------
> =>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)
>

Whoops. You're right. I thought sendmail was compiled using sendmail.cf.
Wrong. I should have diff'd the client and server /usr/lib/sendmail.

---------------------------------------------
> 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

Refer to my question about /usr/spool/mail and /Users above.


---------------------------------------------
> 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

What is it with this /Net thing anyway? I want to understand what Next
intended before I assume it's not for me. I've been studying the way it
works and it is slightly confusing. I can only surmise that it was
intended for read only mounts by the following line in /etc/mtab for the
client stoma (placed there as a consequence of Netinfo setup on the server
biosphere):

stoma:(autonfsmount[87]) "/Net" nfs ro,intr,port=686 0 0

Now, when the exported path "biosphere:/Users" is mounted on stoma, it is
done as follows (also from /etc/mtab on the client):

biosphere:/Users "/private/Net/biosphere/Users" nfs rw,bg,intr,noquota,net
0 0

The server's name is slipped into the path. Netinfo set that up. As part
of the mount a soft link /Net/biosphere to /private/Net/biosphere is
created. What causes this to be done? Autonfsmount? Also how does
/etc/mtab get updated with mounts that I can't find in /etc/fstab? How are
these /Net mountings (such as /Users) being directed?

Now while /Net is read only, which is also obvious from its permissions
dr-xr-xr-x, I assume that read/write directories (like /Users) can still
be mounted to it and accessed as read/write by making a soft link /Users
to /Net/biosphere/Users for example? I get this idea from observing how
/usr/spool/mail appears to give universal access to the restricted path
/private/spool/mail.

---------------------------------------------
> /etc/rc, up the # of nfsd processes from 6 to at least 8.
>

Why is this be unreliable? It isn't clear to me that /Users is
automounted. Just /Net. Why this bump up in processes?

---------------------------------------------
> And to address a particular misconception:
>
[deleted stuff]...

> 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...
>

I don't get it. Why should Netbooting (with local swap disks) be any more
of a stain on the server than having clients with their own OS and
exporting root to them? Are you saying that serving the OS kernal is a
bigger task than serving root? I would think that virtual memory would
solve that kernal serving problem if the local swap disks were actually
working.

-----------------------------------------------------------------
BTW The new NFS Manager app seems to work great. It took me a while to
figure out what order it wanted me to do things in, but once I did it
seemed to greatly simplify the task. I think it may have a great future.

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