Conference bulova::decw_jan-89_to_nov-90

Assuming these are the three situations you're referring to:

1.    	CLUSTER > set display/create/node=my_node_name
    	CLUSTER > run decw$examples:ico

2.    	MY_NODE > run cluster_name::decw$examples:ico  ! example prog

3.    	MY_NODE > set display/create/node=neighbor's
    	MY_NODE > run cluster_name::decw$examples:ico
 
(1) and (3) both require that either security access has been defined
for the incoming client (could be "*" named), or the workstation
does *not* have a session mgr. running *and* one of two files contain
access information:

SYS$SYSROOT:[SYSMGR]DECW$SERVER_ACCESS_ALLOWED.DAT
SYS$SYSROOT:[SYSMGR]DECW$SERVER_ACCESS_TRUSTED.DAT

(2) doesn't require it *because* it's running on your local node.
All you're doing is retrieving the image from cluster_name:: but
it's executing locally.  Thus, no security issue.

Hope that helps,

               == ken miller ==

    re:.0.  Keep in mind the DECwindows does *NOT* use the proxy access
    facilities of decnet.
    
    						monty

    
    .2 is a good piece of info.
    
    .1: Answer to 3 is right. The session manager was not running on
    my neighbor's m/c.
    
        Answer to 2 is conincing because we are just invoking the 
    application.
    
    However to 2, thew answer sounds logical but there is supposedly
    a bug. I recreated the situation today. First time, I allowed login
    access to requests from the cluster to my m/c. Ico ran properly.
    
    	CLUSTER_NAME>set disp/create/node=my_node
    	CLUSTER_NAME>run decw$examples:ico
    
    Next I went and removed the login permission on my m/c, did an 
    apply on the control panel, and saved the resources in my SM. I
    ran ico again. ICO will not go. It ran well.
    
    Ramesh

    Re:.3
>    ran ico again. ICO will not go. It ran well.
    
    Please reiterate.  Ico did connect to the server or it failed to
    connect?
    
    						monty

    When Ico was invoked again, it showed up on my workstation 
    without any problem, although the login permissions had been
    removed. 
    
    Sorry for the pun.
    
    Ramesh
    

    
    Bring down the security menu after this.  What is in the allowed remote
    client list?
    
    						monty

    I don't think I understand your question. My side of the security
    does not have any login permission from any cluster member or cluster
    name. 
    
    If you follow the events, first I allowed login permission, ran
    ico - fine, then I removed login permission, ran ico again.
    What should happen ? Ico should not come. But Ico did. Remember
    after removing login perms I did an "aaply" as well as a "save
    new settings" in the sm.
    
    Hope I am making it clear.
    
    Ramesh
    

    re .7: "from cluster member" must be "for any cluster member".
    
           "aaply must be "apply"

    
    What I was suggesting is that you report to me the security information
    contained in the security pulldown *after* the point where ico is run
    and connects when you think it shouldn't.  However, that would only
    tell me what the session manager *thinks* the security information is.
    I put a program, xgethost, in Vmskit::Decw$Public:[Unsupported].  Copy
    it and run it with decw$display pointing to your workstation after the
    unexpectedly successful ico run and relate the output of xgethost here
    or in private mail.
    
    						m

    I cannot get ICO or any other application to display on my workstation
    running from a remote node even though i set up the authorization
    
    this is what i did 
    
    On my_node set up the security in the session manager permitting
    my  remote_node::username. I saved the settings on the session manager
    after applying. 
    
    On remote node
    
    $ SET DISPLAY/CREATE/TRANS=DECNET/NODE=MY_NODE
    $ RUN DECW$EXAMPLES:ICO
    
    i tried running other application also, each gave a different error
    
    ICO gave the following error
    
    Cannot open display
    : non-translatable vms error code: 0x209c message:
    %system-f-login, login information invalid at remote node.
    
    I dont know why this  should happen when there is authorization
    available. All in all i have not been able to display any application
    run from a remote system.
    
    Ravi

    Re:.10  "login information invalid..." almost certainly indicates a
    version mismatch in the decwindows software.  Someone is using Xn for
    object names while the other is using X$Xn.  Also note that cluster
    names are *not yet* supported in security authorizations.
    
    						m

                   
 DECwindows Security will not give my batch job access after I log out.

    The batch job sets the display, then runs a DW conversion
    tool. It converts a RAGS file to PS, SIX, FSE, DDIF, and 
    SDML formats in about a minute or two. 

    During the day we process about 25+ of these batch jobs, which
    slows down the interactive processes.

    It would be nice to put them on hold until we log out, and let them 
    eat-up some of that idle CPU time. But the DECwindows Security
    is in the way. 

    Can I set my DECwindows Security list to remain active after I log out?

    Is there any way to run a DECwindows program when I am not logged 
    into DECwindows? 

    Do we need to protect the screen if it is not in use?
 
 Kim Rexford
 CUP/ZK Graphic Designer
 381-1282
 

Create a file in SYS$MANAGER called DECW$SERVER_ACCESS_ALLOWED.DAT with
any text editor.  In this file, records describe access to the server when 
no one's logged in.

An example of such an access record looks like this:

DECNET MYNODE MYUSERNAME ALL

Items in the record are:
(transport) (nodename) (username) (access, ALL or NONE)

This would allow the user MYUSERNAME on node MYNODE to have access to the
server using the DECNET transport.  You may use the asterisk wildcard in place
of any of the four items.  For example, the following record would allow user
MYUSERNAME access to the server using any transport from any node:

* * MYUSERNAME ALL

Use caution when giving access to the server though, this opens certain
security holes.

bob

    re: .11
    > ...cluster [alias] names are *not yet* supported in security
    > authorizations.
    
    Supported or not, it is actually quite trivial to make cluster alias
    names work.  We've been using cluster alias names (exclusively) in our
    workstation security lists for many months without any problems.  Here
    is the only change necessary to enable it:
    
    ! Define the X$X0 object on cluster members to use the alias name...
    NCP> DEFINE OBJECT X$X0 NUMBER 0 ALIAS OUTGOING ENABLED
    NCP> SET OBJECT X$X0 NUMBER 0 ALIAS OUTGOING ENABLED

Re: .14

	Indeed, that is all that is required to get cluster alias to work.
	We've not supported it because of the performance implications.  It
	increases the roundtrip time significantly (messages have to go
	through the cluster router).  We hope that Phase V will help with
	this, but to make sure, will test it when its available. :-)

James

    re: .15
    	I agree with you... We have 22 node cluster of 8800's and when we
    had the cluster aliasing the performance of DECW applications running on
    cluster was horrible. It took several seconds to pulldown menus etc..
    
    Robert

    
    
    	VAXclusters are supposed to be a single security domain.
    
    I'd like to see an authorized cluster user authorized to display
    from anywhere in that cluster to her/his own display server.
    
    I'd like to see an remote user authorized by proxy access his/her
    own display server.
    
    	What do you say?
    
    		Paul Komar.
    		VAXcluster Technical office.
    
    	Disclaimers:
    
    	The views expressed above are personal and do not necessarily
    represent those of my group.
    
    	VAXclusters have the potential to be a single security domain.
    
    		-pk

    Re: .17
    
    Can't you set the alias incoming and outgoing enabled on the X$X0
    object, and then just add CLUSTERNAME::USERNAME as one entry under
    the "customize security" pulldown?  I would bet that you'd have to
    have all the nodes in you Vaxcluster in the same area, though...
    
    
    Dave
    

>    Can't you set the alias incoming and outgoing enabled on the X$X0
>    object.

This was specifically discouraged a while back. I think for 
performance reasons.

    It is possible (easy in fact) to enable the cluster alias to work.  But
    the performance cost is significant.  The typical roundtrip time will
    be twice what it normally is, and could easily rise to three times.
    Perhaps Phase V DECnet will have a better implementation of cluster
    alias.
    
    James