Conference csc32::consolemanager

Connie,

>>Several customers have asked about maintaining a single C3 view across user
>>accounts.  Currently the console$c3.dat file is created in the default
>>login directory of each PCM user so each C3 can have its own customized
>>view.   System managers are asking if there is a logical or mechanism to
>>point to a specific console$c3.dat file as a way to control the C3.  As a
>>point of clarification, I am not asking about access to nodes ... but the
>>layout of the C3 in general.

  Try defining the logical CONSOLE$USER_DEFAULTS in each of the accounts
  LOGIN.COM to point to the same directory, in this directory place the
  CONSOLE$C3.DAT file.

>>Another issue that keeps popping up about the C3 comes from former VCS
>>customers.  They miss the autostart of the C3 on PCM restart or boot.  I
>>know there are lots of issues around this feature, but I wonder if there
>>are any plans to implement the C3 autostart either on the PCM platform or
>>on remote stations in the future.  Suggestions on doing it now are also
>>welcomed.

  We know about this and IT IS NOT going to change (not in my lifetime anyway)
  because we have a security access mechanism built into PCM. With no way of
  knowing who is on the workstation an autostarted C3 is sent to, this security
  would be compromised so we refuse to add it as a feature of the product.

  Now, having said that, there is nothing to stop the customer compromising
  his/her own security by having a batch job run right after the PCM startup
  which fires off one or more C3 processes, this batch job could be submitted
  under different user names.

Cheers,
Phil



  2) 

    An besides, Digital knows what's best for our customers. (Sorry Phil,
    couldn't resist). 
    
    I would side with our customer and give them what they want. If it's 
    a security issue for the customer, then it's up to them tyo decide if
    they want to auto start the C3 and live with the consequences. 
    It was in VCS and I don't remember 1 customer complaining that it was 
    a security issue.
    
    The only real security issue I've heard from customers is that they
    would like to have the console connection password protected. 
    Everytime they connect, they would be prompted for a password. 
    That way, if they left their desk with C3 running, the data center is 
    still secure. To further the point, they have also asked that an 
    inactivity timer be added so that if there is no input after a 
    defined interval, they would have to again enter a password, much like 
    the security on PC's today.
    
    It may be a security issue for some, but for others (and I'd guess the
    majority) it's not. My vote is to give the customer the option and then
    let them decide. 
    
    Dave

Dave,
     in VCS is was not a security risc, as the view from the C3 was always
common to all screens. That is not the case with PCM. I seem to remember it
was customers who wanted the security stuff not just Phil, so why subvert it.

Tell Rae about the customer requirements for password protecting the connect
sessions as she is putting stuff together right now!!!

Cheers Simon....

I know it would be nice to be all thaing to all men, but we don't have the time
to be that. 

    >CONSOLE$USER_DEFAULTS
    
    Have you got a list of these "undocumented" logicals tucked away 
    somewhere? 
    
    >in VCS is was not a security risc, as the view from the C3 was always
    >common to all screens.
    
    I have to differ with you here Simon. Several "black-hole" sites
    considered this a security risk and did not want any automatic C3's.
    You could still disallow access to any nodes console for a particular
    user. The node icon appeared it was just stippled out. A user at
    another station could access any node if they managed to gain access to
    an account that had access to all systems. Those users that didn't have
    access to a particular node would not know when someone had accessed a
    console they *didn't* have access to just by looking at their C3.
    
    Maybe I missed your point the view from C3.....
    
    Dan

Dan,

  Nope, no list, however, this one is documented, but not for the C3 ;-)
  its buried in the eventlist description.

  You will find that defining this logical will cause the following UI
  files to be placed in the directory it points to...

  C3

     CONSOLE$C3.DAT
     CONSOLE$C3_username_MSG.LOG
  
  CONNECT/MONITOR

     CONSOLE$MONITOR_INIT.DAT
     CONSOLE$scriptname.SCRIPT

  EVENTLIST (Only when run via $ CONSOLE EVENTLIST /blah/blah/blah"

     CONSOLE$EVENTLIST.DAT


  This applies to ULTRIX and OSF/1 too, just replace the '$" for an '_'
  and you are all set.

Cheers,
Phil

Gentlemen:

Thanks so much for all the good info.  Looks like I struck a nerve on the
C3 startup stuff, but this is how we can it all sorted out for the
customers.  More later ...

Connie

    >It's buried in the eventlist stuff
    
    
    Like that was intuitively obvious..... ;-}
    
    Regs,
      Dan

  We do things like thiss to make people read
  the docs ;-) Who knows what other stuff is
  buried in obscure places!

  Don't ask me what, even I dont know, but,
  if you ask the right questions, all will
  be revealed ;-)

Cheers,
Phil