Thanks to all who responded, namely
alexl@daemon.CNA.TEK.COM
Jim Battan <battan@sequent.COM>
stern@East.Sun.COM (Hal Stern - Consultant)
kuno@caen.engin.umich.edu (Harumi Anne Kuno )
gmc@premises1.quotron.COM (Greg Christy)
My original problem was that tftp didn't seem to work on my 4/370
(OS 4.0.3). The entries in /etc/inetd.conf and /etc/services are good.
Not surprisingly several things contributed to my confusion.
inetd on this machine seems to ignore kill -HUP, so from the very start
any information I put in there wasn't taken in. Killing and restarting
inetd fixed that. tftpd(8c) says kill -HUP is supposed to cause the
reread. Why does it not?
rarpcd and rpc.bootparamd are apparently needed only for booting clients.
Having those available didn't make any difference.
Not having the -s option in the inetd.conf line makes tftp work very
well, but also leaves the the door wide open for anybody with net access
to get anything unprotected off my machine; not my first choice. On
the other hand the -s option invokes chroot() and all it's
ramifications, mainly that anything you want to get has to have a path
rooted at the tftp root directory specified in inetd.conf, and it can't
be symbolically linked from anywhere outside the tftp directory tree,
either. Hal Stern (ya know, Hal, I'm REALLY REALLY glad you pay attention
to this list) pointed out that another ramification is that 'get' requests
with the tftp root (e.g. /tftpboot) explicitly in the path require
that there be a symlink to self inside the tftp root (e.g. tftpboot -> .)
so that the whole path name can be resolved.
Last but not least, TFM [tftpd(8c)] says that in.tftpd runs with UID=-2
and GID=-2, and some other systems I have show those numbers to
assigned to 'nobody' which is also the owner specified in inetd.conf on
those systems. So I changed the owner from 'root' to 'nobody' on the SUN
and guess what - IT DIDN'T WORK. Now a while ago I got a security
notice from Sun about the fact that 'nobody' should be given UID 32767
and GID 32767 (which I guess is actually a short int -2 on some systems)
so I'm not sure that in.tftpd would really run as -2,-2 anyway.
My solution was to use a tftp root of my own, since I don't boot
remote clients, change the directory name in the inetd.conf entry,
cleverly arrange for the tftp root to be on the same file system as
the X fonts I wanted to access ( oh, did I forget to mention that? )
make the real location of the files be inside the tftp directory tree,
create symbolic links for any other directory that needed them
(e.g. /usr/lib/X11/fonts -> /u/tftproot/usr/lib/X11/fonts), and then
kill and restart inetd. THAT works.
Tony Rick
Tektronix, Inc. Beaverton, OR
email:tonyr@tekadg.adg.tek.com
voice:(503) 627-2942
This archive was generated by hypermail 2.1.2 : Fri Sep 28 2001 - 23:06:11 CDT