Dear Managers,
Sorry to be so late in summarizing, but it took a while to
find anything out!
My original first question:
1) We run accounting on the four client stations in our LAN. When the
machines reboot, accounting comes up on only one of the four clients (always
the same one). As far as I can tell, they all have the same setup. We have
altered the /usr/sbin/acct/startup file in two ways (we wrote one file and
copied it to the other clients). One change was to run nohup in response to a
suggestion on this group; the other accomodates our wish that /var/adm/pacct
have normal protection 660, but temporarily changes it to 664 so that
/usr/sbin/acct/accton can run. Here is our file minus comments:
#! /bin/sh
...comments...
PATH=/usr/sbin/acct:/bin:/usr/bin:/sbin
export PATH
chmod 664 /var/adm/pacct
if _def_reason="`dspmsg acct.cat 63 'acctg on'`"
then :
else
_def_reason="acctg on"
fi
_reason=${1-${_def_reason}}
acctwtmp "${_reason}" >>/var/adm/wtmp
/usr/bin/nohup accton /var/adm/pacct
sleep 2
chmod 660 /var/adm/pacct
Any suggestions as to why this works on one machine and not
the others?
Responses
None were received. I still don't know the answer, but it
appears from the accounting logs that accton actually acts as a
toggle. Commands in the reboot are recorded UNTIL accton is run
(accton itself is recorded), then accounting is turned OFF! Is there
a way to determine if accounting is already running (so I can avoid
running accton again)?
My second original question
2) Some of my students would like to connect with remote
Xterminals and/or PC's running X emulation software. To test this
out, I enabled user-based access to the X server on one client. A
tester tried to login. He got the normal DU/OSF graphical login
screen except for the actual dialog box. Instead of that box, a
message roughly saying "Database for this machine not available"
appeared. He is able to log in via ordinary telnet and then set up
his DISPLAY to run X apps, but it is a bit awkward.
One suggestion as to the problem is the fact that I run with
rshd disabled (for security reasons). Is this in fact the problem and
if so can I get around it without enabling rshd? If it isn't the
problem, any suggestions? Running X apps remotely would be very much
appreciated by my users (I'm aware that the X server can also
represent a security risk.).
Responses
I received only one response:
William Blasingame (waldorf!daleb_at_uunet.uu.net)
which indicated that he was able to connect successfully. More
experimentation and some information from DEC revealed the following:
1) The man xhost page contains incorrect information. xhost cannot
authorize a user, only a host. (Courtesy of DEC Software Support)
2) rshd has nothing to do with the matter, unless the PC software is
trying to invoke it.
3) The following files must be edited:
/var/X11/xdm/Xservers
Put in a line for each remote terminal:
remote:0 foreign /usr/bin/X11/X -nice -2 (Courtesy of DEC)
/var/X11/xdm/xdm-config (Courtesy of X Windows
Administrators Manual,
after a bit of head-
scratching!)
The following lines need to be added:
DisplayManager.authorize: true
DisplayManager.authName: XDM-AUTHORIZATION-1 MIT-MAGIC-COOKIE-1
DisplayManager.setup: /usr/var/X11/xdm/Xsetup_0
DisplayManager.startup: /usr/var/X11/xdm/GiveConsole
DisplayManager.reset: /usr/var/X11/xdm/TakeConsole
For C2 security: /etc/auth/system/devassign
/etc/auth/system/ttys
(Courtesy of a previous summary to this group which I had missed).
After some tweaking to the PC software we finally got this to work!
--
============================================================================
Larry Griffith Dept. of Computer & Info Science
larry_at_garfield.wsc.mass.edu Westfield State College
(413) 572-5294 Westfield, MA 01086 USA
PGP public key available at: http://garfield.wsc.mass.edu/dcis/griffith.html
============================================================================
Received on Fri Mar 08 1996 - 21:57:42 NZDT