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 to doug@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 *
*****************************************************************************
This archive was generated by hypermail 2.1.2 : Fri Sep 28 2001 - 23:05:58 CDT