[2572] in Athena Bugs
Re: new attach
daemon@ATHENA.MIT.EDU (Theodore Ts'o)
Sun Jul 16 14:50:08 1989
Date: Sun, 16 Jul 89 14:49:47 -0400
From: Theodore Ts'o <tytso@ATHENA.MIT.EDU>
To: dkk@ATHENA.MIT.EDU
Cc: bugs@ATHENA.MIT.EDU
In-Reply-To: David Krikorian's message of Sat, 15 Jul 89 21:03:11 -0400,
Reply-To: tytso@ATHENA.MIT.EDU
Date: Sat, 15 Jul 89 21:03:11 -0400
From: David Krikorian <dkk@ATHENA.MIT.EDU>
1. The new attach still dumps core... You'll find a corefile in my
afs homedir named core.attach.
Can you let me know what machine this was on? I'm not sure which
version of the attach binary you're using. (Do you know when/where from
you copied the attach binary from?)
2. The new attach won't let root detach every filesystem. Would
putting "trusted root" in /etc/attach.conf fix this? The problem I
had with this was after a user rlogged into my workstation, activated
it, and eventually logged out. I logged in as root on the console and
couldn't detach /urvd and /srvd... (How does deactivate deal with
this, since it has to detach users' homedirs somehow?)
/etc/athena/deactivate and /etc/rc need to be modified so that the call
to "detach -a" includes the -override (or -O) option. My installation
script does this this automatically, but if a release update was taken
in the interim, or if the binary was just copied into place, this
wouldn't work. This is because trusted users don't get special, magic
powers just by virtue of being trusted users; they need to invoke an
option to do special things. We do need to make sure this change takes
place in the next release.
3. Somehow, attachtab got cleared. I had many filsystems mounted
(with the attach command) but only a few were in attachtab. See
below.
I suspect that because of the above problem, attachtab stuck around long
enough that it got cleared out of crontab. I haven't seen any other
cause of attachtab destruction, but that of course doesn't mean that
they aren't there.
- Ted
