Path: utzoo!attcan!uunet!cs.utexas.edu!usc!ucsd!ucbvax!CS.NIU.EDU!rickert
From: rickert@CS.NIU.EDU (Neil Rickert)
Newsgroups: comp.sys.encore
Subject: Re: Umax 4.3 features
Message-ID: <9006271356.AA04474@cs.niu.edu>
Date: 27 Jun 90 13:56:21 GMT
Sender: daemon@ucbvax.BERKELEY.EDU
Organization: The Internet
Lines: 57


 Dale Courte <ncrlnk!wright!eve.wright.edu@uunet.uu.net> writes:
>
>A few strange things have occured since I installed Umax 4.3. I thought
>I would post these and see if anyone else has had similar experiences.
>
>1) Every 15 minutes or so, tftpd (I guess) is creating a zero-length
>file in /tmp. The files are named tftp.nnnnn, where nnnnn is an integer,
>presumably a process number. I have put an entry in crontab to get rid
>of these each night, but this is quite annoying. I can find nothing in
>either the tftp, tftpd, or inetd man pages which would explain this
>behavior. Is this normal? I would guess not, but I am at a loss as to
>what I may have configured incorrectly.
>
  This behaviour is not new to Umax 4.3.  I had noticed (and reported it
to Encore) in Umax 4.2/nfs.  However I don't believe it is anything to
be concerned about.  Think of it as leaving a record of when 'tftp' was
invoked.

  By all means, run a 'cron' job to clean these up. BUT - ONLY remove the
files if they are empty.  If they are not empty, you might want to see what
is in them.  Here at NIU we don't bother, because tftp is only infrequently
used, so our regular cleanup of the /tmp directory is adequate.

  Here is what seems to be happening:

	When tftp is started up by inetd, it opens the file /tmp/tftp.pid
	as a log file, in which to record error messages.  It then does a
	'chroot' to the directory given in the -s option (you do use the
	-s option, I trust), then it does a 'setuid(-2)'.

	Usually tftp does not discover any problems, but if there are any
	they are written to the tftp.pid file in /tmp.  One might hope that
	if there were no error messages, tftp would clean up after itself.
	But that is impossible, for after the 'chroot' and 'setuid' it can
	no longer remove that file.

 Rather more annoying, although also harmless, is the fact that 'catman' 
leaves behind a bunch of 'whatisxxxxx' files in /tmp.

>2) Twice since intalling 4.3 my home directory has been altered so that
>it is owned by root. I am the sysadmin, so often I do things in my dir
>as root, but I find it hard to believe that twice I inadvertently
>executed 'chown root ~dcourte'. Is there some change with 4.3 which
>could cause some other event to change the ownership of a directory? I
>am quite confused by this.
>
 Are you sure you didn't do some restores from dump tapes to your directory?

 I certainly have not noticed anything like this.  But then when I restore files
from old dump tapes, I create a new directory for the 'restore -i'.  I also
always reply 'n' to the final prompt (change owner/mode of . y/n).

=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=
  Neil W. Rickert, Computer Sci Dept, Northern Illinois U., DeKalb IL 60115
  InterNet, unix: rickert@cs.niu.edu              Bitnet, VM: T90NWR1@NIUCS
=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=