Sun Managers,
Thanks for all the help. The original question:
>>I have a user that thinks any problem with the computer should be fixed
>>with L1-A reboot. I think L1-A should be used only as the next to
>>the last resort. Is doing L1-A often bad for the computers? I have
>>a Sparcstation 1, Sparcstation 1+, Sparcstation 2, and an SLC.
I received over 70 responses, so I will not list the names individually.
Thanks alot!
Summary
-------
I got a brief explanation of UNIX files system.
>The Unix kernel buffers all file system activity, keeping track of all
>modifications in internal buffers, and then schedules
>a time to make the physical changes on the disk when it's conveinient
>for the OS. So unless the system is brought down normally by having
>a sync(1) done, the info stored on disk may or may not accurately reflect
>the state of the world. A program called /etc/update which is started from
>/etc/rc, sync's all file systems every 30 seconds to try to maintain
>their integrity upon crashes.
Almost everyone said that L1-A will not damage the hardware, but can
damage any local file systems. So if a computer has a local disk that
is used for more than swapping it can be dangerous. Several people
included horror stories about having to re-install the OS from tape.
Also, many attributed the "L1-A will fix everything" attitude to the
PC mentality.
Methods of dealing with the user included:
------------------------------------------
1) When (not if) his/her system gets screwed take quite a while to fix it.
2) Explain to the user that the problem should be identified and fixed
permenantly.
3) Explain to the user that other people may be logged in or running
background jobs.
4) Explain to the user the difference between an orderly shutdown and L1-A.
5) Change the permissions on shutdown so that any user can run it.
(This is not practical in my environment.)
6) Explain to management about time lost in fixing problems caused by
overuse of L1-A.
7) You can't stop the user from doing an L1-A, so learn to live with it.
8) Direct complaints from remote users to the culprit.
9) Fix L1-A so that the root password is required for it to work.
(I don't know how to do this.)
10) Take the machine away from the user and give him/her an X-terminal.
11) Provide a captive account that runs fastboot.
12) A ROM change is available from Sun to disable L1-A.
13) Turn on the password in the eeprom and set the security so that
an L1-A only gets the user to the point s/he can either
continue or type a password to get to the other commands.
(I'm not sure the older models have this feature).
14) Shoot the user.
15) Remind the user that the computer is not a PC, but a mini-computer or
mainframe.
16) Disable L1-A. (A C program is included at the end. I haven't tested it.)
17) Disable the break key on server consoles. (An adb script is included
at the end. I have not tested it.)
18) Take the workstation away from the user and give him/her a PC.
19) Require users that use L1-A to fill out detailed forms explaining why
L1-A was necessary.
I received some information and advise to keep in mind.
1) Sync the disk before using L1-A (sync; sync;).
2) After L1-A, do a sync (newer systems) or g0 (older systems) to sync
the disks.
3) Make the console secure so that users cannot boot up single user.
4) Solbourne's allow you to turn off the L1-A abort key.
5) Someone said that the L1-A key should not be turned off.
********************** C Program to disable L1-A ************************
>From tres@roke.rap.ucar.EDU Tue Jul 2 16:35:10 1991
Meg,
It's certainly not advisable, but probably not too big a deal in most
cases if the user syncs the disks from the PROM before rebooting (in the old
PROM, typing 'g0' [that's a zero] forces a panic and syncs the disks, in the
newer OpenProm, just type 'sync'). But I wouldn't be too happy about a user
rebooting machines on a whim.
Here's a small C program I got somewhere which allows you to disable
the L1-A abort sequence. Works for me. Good Luck.
-- Tres Hofmeister tres@ncar.ucar.edu/* * abort_key - enable or disable L1-A abort sequence. * Usage: abort_key y|n */
#include <sys/types.h> #include <sys/ioctl.h> #include <sundev/kbd.h> #include <sundev/kbio.h>
main(argc,argv) int argc; char *argv[]; { struct kiockey key; int fd; int mode; char *c;
if (argc != 2) { printf("\nUsage: abort_key y|n\n\n"); exit(1); }
switch (*(c= argv[1])) { case 'y': mode = 1; break; case 'n': mode = 0; break; default: printf("\nInvalid Argument\n"); printf("Usage: abort_key y|n \n\n"); exit(1); }
fd = open("/dev/kbd", 1); if (fd < 0) { perror("OPEN"); exit(1); }
key.kio_tablemask = KIOCABORT1;
ioctl( fd, KIOCGETKEY, &key); /* read abort key entry */
if (key.kio_station == 0) printf("L1-A reset sequence was disabled\n"); else if (key.kio_station == 1) printf("L1-A reset sequence was enabled\n");
if (mode == 1) key.kio_station = 1; else key.kio_station = 0;
ioctl(fd, KIOCSETKEY, &key); /* map it to a 'hole' in map */
if (key.kio_station == 0) printf("L1-A reset sequence now disabled\n"); else if (key.kio_station == 1) printf("L1-A reset sequence now enabled\n"); } ******************** End C Program ************************
******** adb script to disable break key on servers ***** From: Mark Nichols internet: mnichols@pacesetter.com
We use the following adb script to disable breaks on our server consoles. Users get kind of nasty when you inadvertently hit the break key while trying to hit the setup key. This might provide an additional level of security when augmented with setting all the entries in /etc/ttytab to unsecure on the clients as other people have suggested. We have this patch installed on all of our Sun 3 and Sun 4 systems running Sun OS 4.0.3. We don't have any 4.1.1 machines yet so I can't tell you if it will still work under 4.1.1.
----- Cut here ---- #! /bin/sh # Patch to disable the BREAK key and L1-A in one fell swoop adb -w -k /vmunix /dev/mem << EOF montrap?w0x4e75 montrap/w0x4e75 EOF ***********************************************************
Meg Grice Unix Sys Admin, UMKC mlg@cssparc1.cstp.umkc.edu (816) 235-5212
This archive was generated by hypermail 2.1.2 : Fri Sep 28 2001 - 23:06:21 CDT