Hi Joann,

Some more comments:

Joann Ruvolo wrote:
>
> Trevor, thanks for the WebShell feedback. Here is a summary of the WebShell
> problems based on your comments and those of others, and responses.
>
> 1) SCROLLPrompt of Yes.
>
>    This can be fixed in a few ways. The first way is what you mentioned, set
>    SCROLLPrompt to No in dsm.opt. The second way is for WebShell to override
>    the dsm.opt SCROLLPrompt. The third way is to add a line containing c (for
>    continuous) to the WebShell ADSM response file, adsmresp.ws.
>
>    It looks like the third way will only work for AIX right now. WebShell
>    will be modified to include the second fix and the third fix for the
>    PC platforms.
>

For the moment, I'm going to leave SCROLLPrompt set to no. Out of the
three possible fixes, I prefer number 2. Number 1 removes functionality
for command-line clients and number 3 sounds more like a workaround than
a fix.

> 2) Inability to restore inactive versions of files.
>
>    This sounds like an important requirement so we will look into this.
>    Unfortunately with the lack of a real ADSM API these sort of features
>    are awkward to implement.
>

I'm not too sure what you mean when you say 'lack of a real ADSM API'; I
thought that the Webshell would have access to the full api.
Nevertheless, yes it is an important requirement. But I guess it is the
old 80/20 rule; 80% of restores are typically going to be the latest
version.

> 3) Crude user/password maintenance procedures.
>
>    A major concern of Web applications is security, so it was important
>    to devise a Web authentication scheme for WebShell. But if maintenance
>    is an overriding concern, Web authentication can be provided as an
>    option for WebShell. So when running in a secure intranet, authentication
>    can be turned off, via say a command line argument. If this is a useful
>    feature please let me know.
>
>    As far as the ADSM password goes, that is still required if you are not
>    running with a password of generate. If you have suggestions for making
>    this or any other procedure less crude, please let me know.
>

I guess what I would really like to see is the security tied more with
the operating system security i.e. I would like to see the requirement
that all users of the Webshell are authorised users on the node where
the Webshell is running, and the password entered is the operating
system password for that user. That means that we would get to take
advantage of the operating systems password security mechanisms such as
minimum password lengths, password lifetimes, etc. There still would
need to be a mkwspswd file of sorts. But I would like to see that
contain just the users who are authorised to use the Webshell, and what
type of user they are 'u' or 'a'.

> Please forward any additional comments/suggestions.
>
>  Joann Ruvolo                             IBM Almaden Research Center
>  VNET:     RUVOLO@ALMADEN                 K56/803              (tie) 457-1450
>  Internet: ruvolo AT almaden.ibm DOT com         650 Harry Road       (408) 
> 927-1450
>  E Mail:   ruvolo AT zorg.almaden.ibm DOT com    San Jose, CA 95120   (fax) 
> 927-2100

--
Trevor Foley                             Phone: 61-2-9259 3944
Trevor Foley                             Phone: 61-2-9259 3944
Senior Technical Consultant                Fax: 61-2-9259 9844
Bankers Trust Australia Limited         E-mail: Trevor.Foley AT BTAL.COM DOT AU