Re: Re[2]: Admin deleted, job not run
1998-07-30 19:29:09
Hi,
Time for my 2 cents worth.
I have no problem with schedules being associated with administrators,
and those schedules not being able to run if the administator is
deleted. However, I do have a problem with not being told that something
I am about to do ie delete an administator, is going to have an adverse
affect on my ADSM server. And I think that is is unreasonable to have to
remember to check for these sorts of things. We have a few dozen
administrators with enough privilege to add/update schedule (mostly
within a single domain) and maybe 100 scheduled events.
What I'd like to see is that when a 'remove admin' is performed, a check
should be made that there are no schedules associated with that
administator. I see it working along the lines of a 'remove node' where
a check is made that there is no data stored against that node.
Trevor
> -----Original Message-----
> From: Nicholas Cassimatis [SMTP:nickpc AT US.IBM DOT COM]
> Sent: Thursday, July 30, 1998 3:59 AM
> To: ADSM-L AT VM.MARIST DOT EDU
> Subject: Re: Re[2]: Admin deleted, job not run
>
> Jerry,
>
> In my experience with this, the best thing to do was to LOCK the ID of
> any
> admins who leave. After a few months, I'd lower them to OPERATOR
> status,
> unlock the ID, and see if anything fails (keeping an eye right on it
> to run the
> scheduled operation manually). I can then update those schedules, and
> delete
> the ID safely.
>
> Nick Cassimatis
>
> nickpc AT us.ibm DOT com
>
> If you don't have the time to do it right the first time, where will
> you find
> the time to do it again?
>
>
>
> ADSM-L AT VM.MARIST DOT EDU on 07/29/98 01:43:55 PM
> Please respond to ADSM-L AT VM.MARIST DOT EDU
> To: ADSM-L AT VM.MARIST DOT EDU
> cc:
> Subject: Re[2]: Admin deleted, job not run
>
>
> Richard -
>
> The problem we would probably get into here is one with the security
> department - While the root user concept is a fundamental part of
> Unix, it is
> not a mainframe concept. The security folks in my shop have a
> "mainframe
> mindset" that basically says that ids will not be shared between
> people.
> Since there is an alternative (of sorts) here -they probably wouldn't
> approve
> this type of approach.
>
> The bureaucratic mind never fails to amaze me.
>
> Jerry Lawson
> jlawson AT thehartford DOT com
>
> ______________________________ Reply Separator
> _________________________________
> Subject: Re: Admin deleted, job not run
> Author: owner-adsm-l AT VM.MARIST DOT EDU at SMTP
> Date: 7/29/98 8:48 AM
>
>
> >In my shop, that would bring ADSM to its knees, since I set up all of
> >the automation using my id.
>
> I think the obvious solution here is to simply define a general
> administrative
> ID within a shop (much like root on a Unix system) and use that for
> administrative tasks involving configuration changes where ADSM is
> sensitive to
> the administrator ID. Use private administrator IDs for queries, Set
> commands,
> and the like. Individual administrators can then come and go, but the
> general
> one can persist.
> Richard Sims, Boston University OIT
|
<Prev in Thread] |
Current Thread |
[Next in Thread>
|
- Re: Admin deleted, job not run, (continued)
- Re: Admin deleted, job not run, Eric van Loon
- Re: Admin deleted, job not run, Dwight Cook
- Admin deleted, job not run, Tom Brooks
- Re: Admin deleted, job not run, Sheelagh Treweek
- Re: Admin deleted, job not run, Cunningham, Jennifer
- Admin deleted, job not run, Jerry Lawson
- Re: Admin deleted, job not run, Richard Sims
- Re[2]: Admin deleted, job not run, Jerry Lawson
- Re: Re[2]: Admin deleted, job not run, Nicholas Cassimatis
- Admin deleted, job not run, Tom Brooks
- Re: Re[2]: Admin deleted, job not run,
Trevor Foley <=
- Re: Re[2]: Admin deleted, job not run, Nicholas Cassimatis
- Admin deleted, job not run, Tom Brooks
|
|
|