Conference turris::digital_unix

9147.0. "DU V4.0A C2/NIS questions" by RHETT::AMAN () Wed Mar 12 1997 16:09

    My customer's NIS master is running Digital UNIX V4.0a and C2.  He is
    seeing some strangeness that I haven't seen before.  Can anyone explain
    any of the following -
    
    1.  First, if your C2/NIS master is running V4.*, is it necessary that
    all of the C2/NIS clients run V4.*?  This customer couldn't get any
    V3.2* clients to work.  Then he noticed in the doc that the first step
    on all procedures for setting up NIS/C2 environment says "Ensure that
    Digital UNIX Version 4.0 or higher is installed".  Is this because
    we're now using the auth.db, and V3.* systems don't know how to look
    there?
    
    2.  When running /usr/bin/X11/dxaccounts to add new NIS/C2 users, the
    field "u_owner" is added automatically to the user's
    /var/yp/src/prpasswd entry.  The problems is that is always gives the
    value as another user!  So, for example, below he just added user
    "dectest", put it adds "u_owner=aadlplg" to dectest's entry!  I did
    check the default file, and "u_owner is not defined there.  The uid's
    are fine.  Also, user aadlplg doesn't own anything in root or usr, just 
    his own files.  Every new user has "u_owner=aadlplg" in it's prpasswd
    entry!   
    
    # ypcat passwd|grep dectest
    dectest::215:24:DEC test account:/home/cadusr1/dectest:/bin/ksh
    # ypcat prpasswd|grep dectest
    dectest:u_name=dectest:u_id#215:u_owner=aadlplg:u_succhg#858023438:u_pwchan
    ger=root:u_oldcrypt#0:u_unsuctty=INET#alpha1.sps.snds.com:u_unsuclog#858025
    951:u_numunsuclog#2:chkent:
    # ypcat passwd|grep aadlplg
    aadlplg:Jyo4tkk1i4J8I:193:16:0959 GARTON LARRY:/home/admacct/aadlplg:/bin/k
    sh
    # ypcat prpasswd|grep aadlplg
    (i snipped out the dectest entry)
    aadlplg:u_name=aadlplg:u_id#193:u_pwd=Jyo4tkk1i4J8I:u_succhg#0:u_oldcrypt#2
    :u_lock@:chkent:
    
    
    3.  Last, I'm not sure if this is C2 related or not.  It might just be
    a new NIS thing for V4.0.  He is NIS serving groups.  His main group
    (we'll call it staff) has many users in it.  The line goes over the
    1024 character limit.  Something is automatically breaking up this
    large group into 3 groups - same name and same gid.  This is ok, except
    the "groups" command doesn't pickup users unless they are in the first
    occurance of staff.  I have often told customers that run into this
    limit to break staff into staff1, staff2, etc, all with the same gid
    and this seems to work, and even the "groups" command properly places
    the users in the first occurance of the group.  But this customer says
    he found the group broken up, the concatenated them all back, and later
    that day it was broken up again.  What is doing this and why doesn't
    "groups" pickup users in the 2nd and 3rd occurances of the group?  I'm 
    going to try and replicate this here...
    
    Thanks for any input,
    janet
    csc/cs
    
          

    To answer some of the issues (with help from Ann!)
    
    1.  It seems that a V3.* client should work with a V4.* NIS/C2 master. 
    I haven't had a chance to try this myself, and the customer has gone on
    to other issues.  Apparently, the instructions in the manual are meant
    to encourage an upgrade, and it's recommended that they all be running
    V4.*, since there were so many code changes.
    
    2.  We can't reproduce this issue at will.  Once dxaccounts gets
    'stuck' on a u_owner value, it gets added to all new accounts until you
    exit and restart dxaccounts.  I've elevated this one.
    
    3.  I reproduced this issue.  The /var/yp/src/group entry that is over
    256 characters gets split up by dxaccounts.  If you lock or unlock an
    NIS/C2 user the split happens.  I don't know what else may trigger this
    to happen.  The problem is that there is no workaround.  If you rename 
    the groups to different names and same gid, that's great, until you run
    dxaccounts again.  It finds multiple group names with the same gid and
    renames them back.  I don't see a work round for this.  I also didn't
    see this noted in any Release Notes of dxaccounts doc...  I've elevated
    this one also.
    
    janet