Only one reply with an alternate type definition attached, and saying that the
default pretty much never works. In our case, the lock has worked for almost a
year of routine use. It seems rebooting clears the problem. My theory is that on
power failure, the client workstations booted up before the server. This caused
the clients to come up before NIS+ services were up, thus no authentication, and
thus the security error.
Original question:
PARCstation 20s and 10s on Solaris 2.5 running CDE 1.0.1 with some patches
(list available on request):
There was a particularly bad power failure last week while I was on vacation (of
course). A few machines lost a few frequently used files or links, but most
appear to have recovered their filesystems without problem.
BUT, many of these systems now respond to the user clicking the CDE front panel
lock by beeping (and not locking the display). Entering dttypes shows the proper
LockDisplay action, but manually entering "dtaction LockDisplay" also simply
results in a beep. Typing "xlock", on the other hand, successfully locks the
screen. I believe that something is wrong in the tooltalk subsystem, but I
haven't been able to turn up anything. I also tried hunting through the sunsolve
database (while the base's proxy server was working today), but without finding
anything relevent.
Anyone know why these systems won't lock their screens using the normal user
actions?
Answer from Kevin Davidson <tkld@cogsci.ed.ac.uk>
Assuming all the systems are now identical (same patches etc), but it
works on some, and not others, then it *could* be ToolTalk (I don't
see why it should be...)
You can (and should) rebuild the tooltalk databases using ttdbck.
ttdbck -I /TT_DB
ttdbck -I /usr/TT_DB
ttdbck -I /export/home/TT_DB
etc.
I strongly recommend using a partition_map file to move the TT_DB
directories *off* / and /usr. They should not be dynamic
fileysystems. Put them in /var/tooltalk. Here's ours:
# cat /etc/tt/partition_map
/ /var/tooltalk/root
/usr /var/tooltalk/usr
In my expereience (Solaris 2.5.1, CDE 1.0.2), however, the Lock
Screen action *never* works. Drop this file as XLock.dt in a dt/types
directory somewhere (eg ~/.dt/types or /etc/dt/appconfig/types/C)
------------------------------8<--snip-snip--8<------------------------------
## Replace broken LockDisplay action
## Built in one claims it cannot lock the screen...
ACTION LockDisplay
{
LABEL LockDisplay
TYPE COMMAND
EXEC_STRING xlock -remote
WINDOW_TYPE NO_STDIO
DESCRIPTION The LockDisplay action locks the workstation. \
You must know the user's or root password to \
unlock the workstation.
}
------------------------------8<--snip-snip--8<------------------------------
Marc S. Gibian
Telos Consulting Services phone: (617) 377-6350
PRISM/TFS email: gibian@stars1.hanscom.af.mil
This archive was generated by hypermail 2.1.2 : Fri Sep 28 2001 - 23:11:43 CDT