ADSM-L

Re: Permissions to run commands

1998-06-29 10:24:17
Subject: Re: Permissions to run commands
From: Steven P Roder <tkssteve AT ACSU.BUFFALO DOT EDU>
Date: Mon, 29 Jun 1998 10:24:17 -0400
On Sun, 28 Jun 1998, Alan Hamilton wrote:
>     The problem is with COMMMETHOD SHAREDMEM.  The shared memory region
> allows clients on a node to communicate faster with the server if both
> are on the same node, but the shared memory region can only be accessed
> by root users.
>     I don't have the manuals handy, but it might be possible to set up
> a different dsm.sys for the administrative client that uses TCPIP
> rather than SHAREDMEM.

That is what I do;  setup a seperate node in dsm.sys for the Shared Memory
access.  The default is TCPIP.  I think you can also chmod +u on the
dsmadmc command (setuid to root), but this opens a sceurity hole.

Everyone has answered the question about why the command fails when not
run as root, but noone has pointed out here that what Craig wants to do
should be run as a Administrative schedule, and not as an external
command.  Craig, to do this:

define sched deldbb type=admin active=yes starttime=hh:mm:ss cmd='delete
       volhistory todate=today-5' day=any
define sched dbbackup t=a active=yes startt=hh:mm:ss cmd='backup db
       devclass=tape type=inc scratch=yes volumenames=....'

...and query them via:

q sched t=a f=d

There are a few more options, so check the book, or do a "help define
schedule" from a dsmadmc session.

I run both my delete volhist and backup processes from administrative
schedules, as well as a whole slew of other neat stuff...

> >dsmadmc -id=operator -password=***** 'delete volhistory todate=today-5

Steve (unVMix Systems Programmer/Dude) Roder
(tkssteve AT ubvm.cc.buffalo DOT edu | tkssteve AT acsu.buffalo DOT edu | 
(716)645-3564 ,
   | http://ubvm.cc.buffalo.edu/~tkssteve)
<Prev in Thread] Current Thread [Next in Thread>