ADSM-L

Re: Some requirements to discuss

1997-01-13 15:52:00
Subject: Re: Some requirements to discuss
From: Bill Colwell <bcolwell AT CCLINK.DRAPER DOT COM>
Date: Mon, 13 Jan 1997 15:52:00 -0500
Text item: Body.822
It would not be outrageous to submit 3 more requirements, since I have read
that there are already 1500+ in the queue, what's 3 more! ;)

They all seem reasonable and desirable, and also familiar too.  I suspect
that they have been submitted before, but an additional submission, with a
high vote count from SHARE might move them along faster.

I can think of different ways that IBM might 'skin these cats'.  For number
one, there should be much better messages coming out of the server which
can trigger automation.  For instance, 'session aaa for node bbb needs a
tape drive for restore; current tape users are reclaim of vol xxxxxx
(process nn)'  A message like this could be useful to many people in
different ways.  I think a lot of requirements would go away if the servers
were gray boxes instead of black boxes.

For number 2, restartable/targetable expiration, I would be happier if the
performance was improved by the same factor as 'q occ' just got improved.
The need to cancel and restart expiration would go away in that case.  But
if they can't speed it up, your req would be good.

Bill Colwell
The Charles Stark Draper Laboratory
Cambridge Ma.

_________________________Reply Header_________________________
Author: ADSM-L AT vm.marist DOT edu
Subject: Some requirements to discuss
01-13-1997 11:56 AM

Date:         Mon, 13 Jan 1997 11:56:47 -0600
From:         Bob Booth - CSO <booth AT chianti.cso.uiuc DOT edu>
Subject:      Some requirements to discuss
To:           Multiple recipients of list ADSM-L <ADSM-L AT vm.marist DOT edu>

Would it be outrageous to submit the following requirements
(or hybrids thereof)?

1:

It seems that I have to babysit my ADSM server alot, because a reclaimation
will start and take forever, thereby hanging up restores and migrations, which
I consider very high priority.  I also view restores to be the highest
priority task that ADSM has, since this is the a large reason why I have an
ADSM server.  I constantly have to cancel reclaimations, and migrations
because someone needs a restore.

I would like IBM to implement priorities based on the administrators wishes,
being able to set priority levels for processes and session types, (a restore
session for example would be one where it requests a tape be mounted).

I would like to have higher priority processes be able to cancel (better yet
SUSPEND). lower priority ones.  This would eliminate many bottleneck
situations.  That way I don't have to buy more tape drives, or sit and
watch my ADSM server all day.

2:

Allow the adminstrator to split the expiration process or start it on a
particular node, or filespace on a node.  Since the expiration process is
such a database hog, I already start it on selected (low use) times.  I
would also like to be able to start it on a node or set of nodes (more than
one expiration run maybe).  This would eliminate the 'cancel and start from
the beginning syndrome'

3:

Security and authentication are lacking from ADSM.  Right now, any host on
the internet can attempt to connect to my ADSM server.  If they happen to
break the password of an adminstrator, they have access to any node.  There
is little or no logging of were this connection is coming from, nor is there
anyway of preventing connections from unwanted hosts.

I have seen the threads about DNS lookups and understand the 'good and bad'
situations, that is why it should be administrator settable (on or off, more
fine grained)??  An implementation of a wrapper around the port, to allow
logging and masking of connections might be a nice solution...

This is a situation that worries me.. User has secure data, backs up
workstation.  User leaves the company, goes to work for 'other'.  User is
on the internet and sets new workstation up to be old NODENAME.  Nothing is
preventing this user from getting at the secure data.. right..?  Bummer huh?

If I had a way of saying (besides at the router level) that only our local
domain has access to our ADSM server (ignoring the NODENAME, looking at the
connection level now).  All bets would be off, and I would also have a log
of the connection (from x.x.x.x port xx).  Look at the TCP wrapper package
that is widely used now.  I think IBM/ADSTAR might be able to implement
something like that.

Enough for now.

Comments?

Bob Booth
<Prev in Thread] Current Thread [Next in Thread>