Bob,

1. When our ADSM server needs a tape drive for a restore, it does
preempt other background processes (i.e. reclamations, migrations, etc.)
so I'm not sure why you're having this problem.   However, I do agree
with the requirement that customers should be able to prioritize tape
resource utilization according to their own requirements.

2. I've been begging for some sort of checkpoint/restart mechanism for
expiration processing for years.  Since we've moved to AIX it's not as
big an issue for us now (once a week, it only runs 8.5 hours on AIX vs.
26-30 hours on our old MVS system).

3. I would recommend looking at a firewall product to prevent internet
access as this exposure is not unique to the ADSM environment but rather
leaves your entire computing environment vulnerable to attack.  As far
as the disgruntled employee scenario you describe, you could make a
policy of 'locking' a node if somebody leaves your company.  For
administrator access, I would strongly recommend removing or locking the
ADSM supplied administrator ID (ADMIN ???) and registering
administrative accounts with unique IDs.  At least this prevents
somebody familiar with the product from trying to guess a password...
they'll also have to guess the admin ID.

Tim Pittson


>----------
>From:  Bob Booth - CSO[SMTP:booth AT CHIANTI.CSO.UIUC DOT EDU]
>Sent:  Monday, January 13, 1997 12:56 PM
>To:    Multiple recipients of list ADSM-L
>Subject:       Some requirements to discuss
>
>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
>