Re: tlug: NFS question

[Rex Walters <rex@example.com>]

>>>>> Frank Bennett writes:  (on 14 Oct 98)

> The design strategy (someone step on my fingers if I'm crawling
> in the wrong direction...) is to load processing overhead onto
> the terminals, and to centralize data storage and machine
> configuration details on the server.

You are a very wise man.  Absolutely the right direction (IMHO).

>                                       The terminal machines will
> run Applix and Netscape and what have you, from the disk in each
> terminal.  Data, mail, and bootpd parameters will be stored on
> the server.

You may want to make an install server as well -- to ensure all your
clients are configured identically.

> This will require that the user's home directory be in an NFS or
> other remote-mounted filesystem, and I just realized that I don't
> know how best to set this up, nor indeed whether it will work at
> all.

Sure it'll work.  Unfortunately Linux's NFS client implementation is
quite slow at the moment (faster but flakier in 2.1).  I wouldn't
recommend using Linux as an NFS server if you have another option.

> Am I going to run into massive overhead by exporting /home to
> every terminal (there will be about 20 at the start, but numbers
> will grow; and there will be 300+ subdirectories in /home)?

The number of subdirectories doesn't matter, but the number of clients
and the available network bandwidth does.  Keep in mind that a single 10
Mbps etherent network can only transfer about 1 MB/s, or 3.6 GB per hour
(and bring the network to its knees while its doing it).

20 shouldn't be enough to worry about though.  100 Mbps network gear is
pretty cheap these days.  If you can afford switched 100 Mbps, try to put
more than one interface on the server and dedicate a switch port to each
interface.  Then ensure your clients mount from each interface evenly.

>                                                              Will
> this require that the /etc/password on the server is cloned to
> the client to assure that permissions are synced between the two
> systems?

No, the server doesn't have to have any entries in /etc/passwd.  All
permissions are stored in the filesystem and passed over the wire as
uid/gid numbers.  You only need /etc/passwd entries if you want an "ls"
on the server to show you names rather than numbers.  I recommend
limiting the logins in /etc/passwd on the server to an absolute minimum.

The *clients* however must be in sync.

>           Are permissions on an NFS-mounted filesystem going to
> be as easy to walk around as, thinking idly about the problem
> here at my desk this evening, I think they will be --- by hacking
> the /etc/passwd ID number or password on the client machine?  It
> all seems rather scary somehow.

You must somehow ensure that all of the user<->uid, group<->gid mappings
are identical on all of the clients.  This can be accomplished using NIS
or by rdist (I'd actually recommend the latter).

> Or is there another, better method of accessing remote data in
> filesystem form that I can apply here?

You can look at the coda project (succesor to AFS) but I'd strongly
recommend sticking with NFS unless you're doing this more for
hacking/learning than to ease administration.

NFS is a simple protocol with a lot of ugliness, but it's also easy to
understand and fix problems.

> If the answers are complex, please feel free to just point me at
> suitable readings.  I'm happy to study, but don't want to spend
> my time reading up on dead-ends.

I'm paid to be an NFS expert -- feel free to let me know any problems
you may encounter.

Regards,
-- 
Rex
---------------------------------------------------------------
Next Nomikai: 20 November, 19:30 Tengu TokyoEkiMae 03-3275-3691
Next Meeting: 12 December, 12:30 Tokyo Station Yaesu central gate
---------------------------------------------------------------
Sponsor: PHT, makers of TurboLinux http://www.pht.co.jp