[2753] in testers
[daemon@ATHENA.MIT.EDU : sun4 7.7K: afsd]
daemon@ATHENA.MIT.EDU (mhbraun@MIT.EDU)
Wed Jan 4 16:58:52 1995
From: mhbraun@MIT.EDU
Date: Wed, 4 Jan 1995 16:58:27 -0500
To: testers@MIT.EDU
We might want to correct some of this in the patch release.
Matt
------- Forwarded transaction
[13073] daemon@ATHENA.MIT.EDU (jhawk@MIT.EDU) Athena Bugs 01/04/95 16:50 (45 lines)
Subject: sun4 7.7K: afsd
Date: Wed, 4 Jan 95 16:50:28 -0500
To: bugs@MIT.EDU
From: jhawk@MIT.EDU
System name: w20-575-27
Type and version: SPARC/5 7.7K
Display type: cgthree
I attempted to send this bug report two hours ago and somehow failed...
I tried to login and could not obtain tickets due to five bugs
pertaining to time and AFS.
1) Three sparc 5's in the w20 cluster (26,27,28) had their time
set 10 minutes slow at the time of installation. They presumably
lost this time while they were off, reflecting shoddy Sun hardware,
being a hardware bug. Complain to your SMCC sales rep.
2) The people installing the machine did not attempt to login and
confirm the machine worked (per last), nor did they reset the time.
3) /etc/init.d/athena attempts to run /etc/gettime instead of
/etc/athena/gettime to set the initial time upon boot. This doesn't
work as there is no /etc/gettime.
3a) gettime by default attempts to set time from a nonexistant .arpa
server. This should be fixed in the sources (I recommend time.mit.edu).
*4*) afsd does not seem to correctly set the time. It should (since it
is not invoked with -nosettime) attempt to do so periodically,
and syslog it's attempts. I'm not familiar enough with afs
internals to do debug this problem, and the lack of a working
syslogd excacerbates my difficulties.
5) Comments in /etc/athena/rc.conf imply that setting TIMECLIENT to
true will activate timed:
TIMECLIENT=true; export TIMECLIENT # Timed client?
The comment should be either "# Time client", or TIMECLIENT
should cause timed to be run.
--jhawk
--[13073]--
------- End forwarded transaction
