Conference azur::mcc

Whoops,

It looks like all commands need the USER, PASS. Also, things look a bit worse
than expected. I can't get the sink started even after the procedure runs
without error???? I don't even get a log file like I used to. The only log
being created is a netserver.log every time the startup is run. The process
does not show up with a SHOW SYS. There is no DECnet link to EVL and there
is no STATE NAME when you look at logging.

help appreciated,
brad...

I'm seeing the very same thing, w/o the privelage violations.

Just installed T1.2.7 on a V5.5 VMS system.  When the MCC_STARTUP_DNA4_EVL
command procedure runs all appears normal, but no object is created and no
process is started.   No log files are created.

Al

Just tried doing a $ RUN/DETACH SYS$LIBRARY:MCC_DNA4_EVL and the network
object was created as well as a process id.

I would image that the developers had a few more switches in mind, but somehow
the command that does the RUN must have been left out?

I am now able to received DECnet events as before.

Al

> Just tried doing a $ RUN/DETACH SYS$LIBRARY:MCC_DNA4_EVL and the network
> object was created as well as a process id.

This also worked for me. thanks.

> I would image that the developers had a few more switches in mind, but somehow
> the command that does the RUN must have been left out?

It would be nice to know if this is a clean work around from a developer. I am
hesitant to put this up on our production system until I know.

brad...

    
    Brad,
    
    this workaround should be fine.  You're emulating our debug environment
    with this.
    
    This bug surprised me, but we understand where it came from and the
    problem is being addressed for SSB.
    
    Here's a quick rundown:
    
    o We found another concurrency issue with our use of NMLSHR at the very
      last minute in the DNA4_AM.
    
    o After several quick attempts at patching the problem failed, we 
      decided to use our MCC_DNA4_AM_LOG logical to disable the use of 
      NMLSHR from DECmcc for field test update.
    
    o The new behavior you are seeing is because even local requests to 
      DNA4 with this update use DECnet access and not the semi-supported
      NMLSHR interface on VMS that we all know and love.
    
    We are working on correcting the root problems right now, so you won't
    see this problem in any successive update or the SSB version.
    
    Thanks for pointing it out quickly, and thanks for the workaround,
    we'll make sure that field test sites are made aware of the problem and
    the workaround so that they stay up and running as well.
    
    -Jim Carey
    

Jim,

Thanks for the timely answer. This was the only bug I saw holding me back
from putting this kit into production for the 'real' shakedown.
    
>    Thanks for pointing it out quickly, and thanks for the workaround,
>    we'll make sure that field test sites are made aware of the problem and
>    the workaround so that they stay up and running as well.
    
The workaround praise goes to Al for this one.

best regards,
brad...    

Brad -
	Also everyone else trying to start up the phaze-iv event sink...
        Below is a modified startup file like the one which comes with
the kit. I have found that by setting the mcc_dna4_am_log bit in the
bms and dir startup command procedures we have run into a small got'cha'. 
	There are 2 work arounds...
	( 1 ) The account that you start up the phaze-iv sink from
              must have proxy to itself.
              --- example ---
              $ set def sys$system
              $ run authorize
              UAF> add/proxy local_node::decmcc_account_name privileged_account_name/default
              UAF> exit
              $@sys$startup:mcc_startup_dna4_evl
        ( 2 ) simply modify the startup procedure below and run it.
                                            |
                                            |
                                            |
                                            |
                                            |
    - darryl                                |
                                            v
    
$! 	This command file can be envoked from mcc_startup_dir.com.  It is
$! commented out in the MCC_STARTUP_DIR.COM. To run it on system
$! startup, update the MCC_STARTUP_DIR.COM file to execute the statement:
$!	@SYS$STARTUP:MCC_STARTUP_DNA4_EVL.COM
$!
$! You may also modify the event filter or event sources to tailor the events
$! processed to the specific needs of your network (Refer DECNET PHASE IV 
$! ACCESS MODULE USE).
$!
$! To enable the sink to collect events from EVL, following setups are
$! required.  
$!
$!	1.  Must have default privileges: TMPMBX,NETMBX,DETACH,SYSNAM
$!	2.  Must declare network object task to 0 for VMS before V5.4 systems
$!	3.  The state of the local sink monitor must be off
$!	4.  The local sink monitor must have a name of MCC_DNA4_EVL
$!	5.  The event filter must be properly defined on the node where the 
$!	    sink is executed.
$!
$!	Note: This command procedure is intended to perform all of these
$!	tasks as long as you have the privileges to execute them.
$!
$! Edit the command procedure by replacing <os_node> occurrances with
$! the name of the local system (where DECmcc is located).  If you have
$! appropriate privileges (above), then after excuting this procedure
$! you will have:
$!	- Your Local Sink Monitor setup to be MCC_DNA4_EVL
$!	- A process, MCC_DNA4_EVL listening to DECnet's EVL.
$!	- All supported DECnet Phase IV Events will be passed to
$!	  MCC_DNA4_EVL so that you can GETEVENT against them to
$!	  collect the events.
$!
$! You can modify this procedure to:
$!	- filter unwanted events from being passed to MCC_DNA4_EVL
$!	  to reduce the amount of work the Local Sink process does.
$!	  Change the Create Remote Sink or Pass directives to do this.
$!	- Non-local events can also be sent to this system by setting up
$!	  Remote Sinks on other systems that have an Outbound Stream of
$!	  <os_node>.  This can be done in this procedure, or on the remote
$!	  systems directly.
$!
$!
$!
$! Keep SYS$LOGIN error log files down to a minimum.
$!PURGE MCC_DNA4_EVL.LOG/keep=10
$!
$! check to see if the phaseiv am log bit is set
$!
$ FALSE = 0
$ TRUE  = 1
$ prv_ch = 0
$ phz_iv_log = 0
$!
$ if 'f$trn("mcc_dna4_am_log")
$    then
$       !
$       ! check to see if the setprv priv is on
$       ! --- comment ---
$       ! if you can't set this privilege the procedure
$       ! will fail with priv violations
$       !
$       if 'f$priv("setprv")
$          then
$             if 'f$priv("nosysnam")
$                then
$                   set proc/priv=sysn 			! just in case it isn't set
$                   prv_ch = 1
$             endif
$       endif
$       phz_iv_log = 'f$trn("mcc_dna4_am_log")
$       accmode   == f$trn("mcc_dna4_am_log",,0,,,"access_mode")
$       tab_nam   == f$trn("mcc_dna4_am_log",,0,,,"table_name")
$       deassign/table='tab_nam'/'accmode' mcc_dna4_am_log
$ endif
$!                                                     
$!
$!manage/enterprise
!
!	Get rid of TASK object and recreate it.
!	Not required for VMS V5.4 or later systems.
!
!DELETE node4 <os_node> object task 
!
!CREATE node4 <os_node> object task number 0
!set node4 <os_node> object task user DECmcc, pass the_right_one
!
!	the state of local sink must be off before clearing up the sink 
!
!DISABLE node4 <os_node> local sink MONITOR 
! 
!	before create the local sink, clear it first
!
!DELETE node4 <os_node> local sink MONITOR 
!
!CREATE node4 <os_node> local sink MONITOR 
!
!	the name of the sink monitor must be MCC_DNA4_EVL for DECmcc.
!
!SET node4 <os_node> local sink monitor name = mcc_dna4_evl
!
!  Make sure no old Remote Sinks are lying around.
!
!DELETE node4 <os_node> outbound stream <OS_NODE> remote sink MONITOR 
!	set up the event filter:  os_node => should be the local node.
!				  os_node => is where events will be received.
!
!  Set up to sink local events of class 0 to the Local Sink Monitor.
!
!CREATE node4 <OS_NODE> outbound stream <OS_NODE> remote sink MONITOR class = 0,-
!	event type = {0,1,2,3,4,5,6,7,8,9}
!
!  Set up to sink local events of class 2 to the Local Sink Monitor.
!
!PASS node4 <OS_NODE> outbound stream <OS_NODE> remote sink MONITOR class = 2, -
!	event type = {0,1}
!
!  Set up to sink local events of class 3 to the Local Sink Monitor.
!
!PASS node4 <OS_NODE> outbound stream <OS_NODE> remote sink MONITOR class = 3, -
!	event type = {0,1,2}
!
!  Set up to sink local events of class 4 to the Local Sink Monitor.
!
!PASS node4 <os_node> outbound stream <os_node> remote sink MONITOR class = 4, -
!	event type = {7,8,9,10,14,15,17,18}
!
!  Set up to sink local events from class 5 to the Local Sink Monitor.
!
!PASS node4 <OS_NODE> outbound stream <OS_NODE> remote sink MONITOR class = 5, -
!	event type = {0,1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20,21}
!
!  Set up to sink local events of from class 6 to the Local Sink Monitor.
!
!PASS node4 <OS_NODE> outbound stream <OS_NODE> remote sink MONITOR class = 6, -
!	event type = {0,1,2,3,4,5}
!
!  Set up to sink local events of from class 7 to the Local Sink Monitor.
!
!PASS node4 <OS_NODE> outbound stream <OS_NODE> remote sink MONITOR class = 7, -
!	event type = {0,1,2,3,4,5,6,7,8,9,10,11}
!
! --- or ---
! create or pass
! pass node4 <os_node> outbound stream <os_node> remote sink monitor -
! named event = { *.* }
!
! --- or ---
! pass node4 <os_node> outbound stream <os_node> remote sink monitor -
! named event = { 0.*, 4.* }
!
!	start the sink -- set it to state on and create the MCC_DNA4_EVL
!	process to receive the events and make them available to DECmcc.
!
!ENABLE node4 0 local sink monitor
!exit
$!
$! re-define the phaseiv am log if it was set...
$!
$ if 'phz_iv_log'
$    then
$       define/system/executive_mode mcc_dna4_am_log 'phz_iv_log'
$       if 'prv_ch'
$          then
$             set proc/priv=nosysn
$       endif
$ endif
$!
$!
$!
$!EXIT
$!
$!
$!

We found this note inadvertently while looking for something else

to .7

> $!	2.  Must declare network object task to 0 for VMS before V5.4 systems

>$!manage/enterprise
>!
>!	Get rid of TASK object and recreate it.
>!	Not required for VMS V5.4 or later systems.
>!
>!DELETE node4 <os_node> object task 
>!
>!CREATE node4 <os_node> object task number 0
>!set node4 <os_node> object task user DECmcc, pass the_right_one
>!

Are you suggesting to write in clear in a command procedure a Username/Password
combination ? is Account DECmcc a privileged account ??? Did-you ever hear of
favourite hackers targets ??? Did you ever think that, by providing such a
recommendation, you could involve Digital's liability ?


Fortunately, this should not be necessary anymore (as specified in the
comments). Remember Digital highly recommended in February 94 to all his
customers to run VMS V5.4-3 or higher while distributing mandatory security
update VAXSMUP03.

Pierre

Because You can mange REMOTE nodes in a WAN, because that is
what DECmcc is built for, and that is how it is used.

If You manage the network part of a remote node, You basically
can gain control ofver the node or make it unusable.

Fantastic !!!!

Read the Introduction to...

Dirk