ADSM-L

Some requirements to discuss

1997-01-13 12:56:47
Subject: Some requirements to discuss
From: Bob Booth - CSO <booth AT CHIANTI.CSO.UIUC DOT EDU>
Date: Mon, 13 Jan 1997 11:56:47 -0600
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>