Hi all,
I posted with a problem with dtcm yesterday, no one, not even root,
could make changes to their calendars. Dr Tom Blinn replied with a reqest
for further information, as it had seemed to me at first check that the
problem was the security patches that I had applied. This was not the
case. It turns out that the user that brought the problem to my attention
was using a machine that had recently been upgraded to new hardware as well
as new software. At some time when moving /var from the old hardware to
the new, the permissions on all of the files in /var/spool/calendar went
from 460 to 400 and the dtcm daemon could not do the updating of the data
files. I was led astray by the fact that this behavior was not noticed right
away after the hardware was changed, but only 2 weeks later when it was
time to make a data entry for a new calendar event! When root could not
write new data to its own calendar, I suspected the patch, and as the
error message was rather cryptic, did not suspect/realize that the writing
of data to the calendar file is done by a daemon and not the users own
process. We learn new things every day. This AM, I came in and decided
to do some more checks on the problem and when I was sucessful writing
calendar data on another machine which had been patched but not changed
in any other way, I looked (again) at the files in the calendar directory
and noticed the protection issue. Checking working against non-working
imediatly showed me the problem. The permission problem may have been
a vdump issue, but I can't be sure at this late date.
Thanks to all
Charley Knox
Associat Astronomer
Dept of Astronomy
Case Western Reserve University
knox_at_grendel.astr.cwru.edu
Received on Thu Oct 14 1999 - 17:53:28 NZDT