[Search for users] [Overall Top Noters] [List of all Conferences] [Download this site]

Conference iosg::all-in-1_v30

Title:*OLD* ALL-IN-1 (tm) Support Conference
Notice:Closed - See Note 4331.l to move to IOSG::ALL-IN-1
Moderator:IOSG::PYE
Created:Thu Jan 30 1992
Last Modified:Tue Jan 23 1996
Last Successful Update:Fri Jun 06 1997
Number of topics:4343
Total number of notes:18308

3019.0. "Group Services and add drawer via set host" by GIDDAY::SETHI (Ahhhh (-: an upside down smile from OZ) Mon Jul 19 1993 05:05

    G'day All,
    
    I have a customer who has ALL-IN-1 IOS 3.0 (unpatched), OpenVMS 5.5-2 
    installed.  The problem we are having is with Group Services option.
    
    A customer adds a group called say R&D and has several distribution
    lists and users.  If a user (Local) has set host to the machine he is
    unable to add the drawer ie ADR than enters the find key the drawer is
    not listed.  However if the user uses set host/lat than the drawer is
    visible.
    
    I remember seeing a note in here that suggested that the *LOCAL group
    will not be able to access the drawer if the user does a set host,
    instead they should do a set host/lat.  The explaination was good so I
    have nothing to ask about the logic behind it.
    
    In this case the user is expliciately part of a group that was created. 
    Therefore from my understanding the user *should* be able to add the
    drawer.  What we did was the following :-
    
    1. Create shared drawer
    2. Create a group list with above users
    3. User logs in via set host and is unable to list the drawer
    4. User logs in via set host/lat and is able to list the drawer & add it
    
    This seems like very odd behaviour.  Is this how GS is supposed to
    work ?  I have not been able to test this on-site as our ALL-IN-1
    systems are currently being worked on.  But I managed to verify all of
    this when I logged onto the customers system.
    
    All the identifiers etc. seem to be correct and all users can access
    the drawer, it's only the add option that is the problem.
    
    Regards,
    
    Sunil The bugglet finder :-)
T.RTitleUserPersonal
Name		DateLines
3019.1Need to re-login?IOSG::MAURICEDifferently hirsuteMon Jul 19 1993 09:4212
    Hi Sunil,
    
    The other main gotcha with groups is a VMS restriction. If I grant an
    identifer to a user then that user will only get that identifier the
    next time the user logs into VMS. Since adding a member to a group is
    in effect granting an identifier to that user, the VMS restriction
    applies to Groups. So ask the user to logout and login again, and see
    if that fixes the problem.
    
    Cheers
    
    Stuart
3019.2*LOCALANGLIN::HARRISAbeep meMon Jul 19 1993 17:5010
    RE .0
    
    Sunil -
    
    is your customer using *LOCAL as a group to give access to ALL users?
    i thought that *LOCAL wasn't working properly?  i know i've seen a DSN
    article on it.  if its been fixed - GREAT!
    
    	ann
3019.3Sorry...but...IOSG::STANDAGEMon Jul 19 1993 17:599
    
    Ann,
    
    Nope, the *LOCAL problems have not been fixed I'm afraid...
    
    
    Kevin.
3019.4Shifting sands story from customer :-)GIDDAY::SETHIAhhhh (-: an upside down smile from OZTue Jul 20 1993 07:4548
    Hi Stuart,Ann and Kevin,
    
    The customer seems to change the problem description as we go along
    :-}.  So I have asked him to send me an EM and I am including the
    details below:
    
    Subj:   requested ALL-IN-1 details
    
    Sunil,
    
    please find description of what happens with shared drawers owned
    by user PUBLIC (others work OK).
    
    User PUBLIC owns shared drawers called COMPUTING and SENSORY.
    
    When updating access to it as user PUBLIC, I had
    PLOM  - full access,
    CHECK - read only,
    *R_DD group (all LOCAL users) - read only.
    
    In this scenario, CHECK had NO problems accessing both drawers
    via FC DRM ADR when using SET HOST and also via LAT (terminal
    servers).
    
    Members of R_DD group could acces only these drawers via
    terminals and NOT from PC's using Reflection 4 (which is using
    LAT). E.g user JLINFORT (member of R_DD group) had access set up
    on terminal and when accessing DRM IAD those PUBLIC owned drawers
    were not displayed at all.
    
    If I removed CHECK from the list, then added to R_DD group and
    updated access, CHECK could NOT access this drawer via set host,
    only trough terminal server.
    
    Regards !
    
    Peter
    
    :-)>>>  (long beard)
    
    ------- End of Customer problem description -------
    
    I cannot reproduce this I am a bit lost, so any help would be
    appriciated.
    
    Regards,
    
    Sunil
3019.5$show proc/privIOSG::MAURICEDifferently hirsuteTue Jul 20 1993 09:4610
    Hi Sunil,
    
    Can you ask the customer to do a $show proc/priv for a user in the
    *R_DD group when accessing via a terminal and also when accessing via
    the PC. It will be interesting to see if the group identifier shows up
    in both cases.
    
    Thanks
    
    Stuart
3019.6Problem has gone auto-magiacally :-), ppphhhGIDDAY::SETHIAhhhh (-: an upside down smile from OZThu Jul 22 1993 03:4114
    Hi Stuart,
    
    I just don't know what is going on with the FCS, the customer told me
    yesterday that they can now access the drawers the problems gone.  I
    left the call open an extra day to make sure that the customer has
    really got rid of the problem.
    
    The customer has assured me that he changed nothing :-}, this sends a
    shudder up my back.  Is it the customer or the FCS ?  I guess we will
    never know, unless others reply to this note giving details.
    
    Thanks for all your help,
    
    Sunil