🚀 go-pugleaf

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 <1992Nov11.152052.8171@menudo.uh.edu> sears@tree.egr.uh.edu  
(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
gcolello@biosphere.stanford.edu