On Saturday night I asked how to connect a diskless 3/50 under SunOS 3.2.

Monday morning there were seven answers awaiting me. Almost all agreed that

what I had forgotten was to set up a symbolic link in the /tftpboot directory

of the server. It links the hex internet address of the client to one of the

ndboot files. In my case, the correct form of the directory turned out to be:

lrwxrwxrwx 1 root 19 Jul 2 19:06 C009C803 -> ndboot.sun3.private

-rwxr-xr-x 1 root 13616 Sep 18 1986 in.tftpd

-rwxr-xr-x 1 root 28000 Sep 18 1986 ndboot.sun3.private

-rwxr-xr-x 1 root 28000 Sep 18 1986 ndboot.sun3.pub0

-rwxr-xr-x 1 root 28000 Sep 18 1986 ndboot.sun3.pub1

lrwxrwxrwx 1 root 1 Jun 23 1987 tftpboot -> .

Most people thought the link should be to ndboot.sun3.pub1, so there must be

something non standard about my setup that required it to point to

ndboot.sun3.private.

With that link set up, the diskless machine was able to get past the

tftp (trivial ftp) part of the boot process. The remaining hurdles had to do

with getting /etc/fstab, /etc/exports, and symbolic links set up properly to

reflect our new configuration. The diskless machine used to be a standalone

that cross mounted other machines' file systems, and several of its links had

to be redefined. It was not necessary to manually start up the in.tftpd or

in.tftpbootd daemons on the server. They must get triggered automatically

when the client boots.

Thanks to all of you who properly diagnosed what I had forgotten to do. Most

answers were sent to me around 11pm - midnight Saturday or Sunday. This

network group is great.

Please permit an editorial on system administration from a programmer who

occasionally must become an amateur administrator. One of the prerequisites

to Unix becoming a mass market product like DOS and MacOS is for mortals to be

able to set up and manage their own systems. The programming community is

finding that the data and implementation encapsulations provided by object

oriented languages enable one to think and program in human terms rather than

in computer terms. Unix is not an object oriented operating system. However,

I hope some enterprising vendor will soon market an interface to it which

enables most tasks to be performed in human terms. The interface would

encapsulate knowledge of Unix administration internals. I'd rather tell Unix:

"Make machine x a client of machine y", and answer any questions it needs to

ask me, rather than having to thumb through sketchy and incomplete manuals,

modify obscure files, do hours of empirical experimentation, grouch at anyone

who wants to use the system while I'm experimenting, and plea for help from

strangers. For starters, even a system that cross references administrative

tasks to manual sections (coupled with clear and complete manuals) would help.

I love to use Unix and hate to administer it. There's got to be a better way.

Thanks todoug@USAN.consult.com, uunet!mcsun!ica.philips.nl!geertj,

ho@la.tis.com,halstern@Sun.COM,aldrich@sunrise.Stanford.EDU,

kink@uncle-bens.rice.edu,jfy@orion.cis.ksu.edu,loki@Physics.McGill.CA,

paul@concour.cs.concordia.ca.

*****************************************************************************

* Bruce Samuelson Internet bruce@utafll.lonestar.org *

* University of Texas at Arlington Usenet ...uunet!texbell!utafll!bruce *

*****************************************************************************