Conference smurf::dec_mls_plus

    Hmm.  If we're lucky, this is Patrick AFB and what they need is 
    a new mltape built with the libsecurity.a that contains the fix done in
    submit request # 6242 for dump/restore and tnmapd (see note 330).
    I cannot find just now where mltape (cpio) does anything with ACLs,
    But do the files in /ace9 have extremely large ACLs (or ACLs at all)?
    
    Hmm(2)  One way for them to verify if this is indeed the problem might be
    to create the mltape archive without ACLs, i.e., use the -A switch
    and see if it succeeds.
    
    Dave is building patch kit level 10 as we speak and I'll ask him
    to include mltape in that kit, Justin Case.
    
    
    All that aside, I have only one question before I start to try
    and check this out. You listed the command as:
    
    mltape -ovO /dev/rmt0h -F "/ace8 /ace9 -print"
    
    but started listing output with 
    
    /ace9/rtdr/NOS/PF/CYBER/.CP317C3.READ.R
    
    ...
    
    Did it really start archiving /ace9 before /ace8 or did someone
    just leave out the output re: /ace8?  
    
    Thanks
    

    Bat,
    
    The customer is Patrick AFB...sort of.  It's really Cape Canaveral AFS
    which is sort of part of Patrick.  (I know because I used to work there
    for RCA from 1978-83; in fact, I recognized the customer's phone number
    because I used to work in the same building!  And he's been there long
    enough that we overlapped, but we don't remember each other.)
    
    The output is exactly as I got it from the customer but I don't know
    if he edited out parts he considered irrelevant.  I'll try to get an
    answer to this as well as your other questions today.
    
    Martin

    They are anxiously awaiting patch kit 10.  The sample output, as you
    suspected, was edited; they just left out all but the 'interesting'
    part.
    
    Martin

    The customer has installed patch kit 10 and reports that it has *not*
    solved the mltape problem.  He says it has also made their NFS
    performance considerably poorer.  He's offered to put the files that
    create the problem on tape and send it in, if that would help.
    
    Martin
    
    PS. I'm in CXO this week so a little slow to respond.

    Yes, I will take whatever they have got so we can reproduce the mltape
    problem.  I guess we'll have to open a real CLD on it.
    
    re: NFS performance: 
    
    Can you ask them to blow away their TNETDB (In Version 3: you have to
    umount the stuff and turn off networking, e.g., :
    
    /tcb/bin/tnetd_stop ; rm /tcb/files/TNETDB 
    
    reboot -OR- /tcb/bin/tnetd_start 
    
    It's probably better to reboot, but if they can't then...
    
    That still may not fix the problem, but it does have to be done so let
    me know first.  We should have said this in the README.

    Where do you want them to send the tape?
    
    Martin

    Barbara Thomson ZKO3-2/X74
    Digital Equip Corp
    110 Spitbrook Road
    Nashua NH 03062-2698

    Did the tapes ever show up?  He sent them last week.
    
    Martin

    Tapes just arrived this morning, haven't unloaded them yet

From: Martin Moore <[email protected]>
Message-Id: <[email protected]>
Subject: Patrick's problems
To: [email protected]
Date: Thu, 15 May 1997 07:58:00 -0400 (EDT)
Cc: [email protected]

Hi Bat,

I got a request from Patrick asking what the status was on their mltape
and other problems.  The 'other' problems are listed in this mail message
he sent me earlier.  I managed to overlook these, my fault; any ideas on
them?  If not, I'll ask Tammy to take a look at them since it looks like
they involve NFS.  Also, any ideas on the mltape problem?

Thanks,
Martin
 
Forwarded message:
> From [email protected] Sat May  3 13:52:40 1997
> Message-Id: <c=US%a=_%p=R-CITIS%[email protected]>
> From: "Major, Sam #CSR2000" <[email protected]>
> To: "'[email protected]'" <[email protected]>
> Cc: "Copp, Joe #CSR2000" <[email protected]>
> Subject: MLS problems
> Date: Sat, 3 May 1997 13:53:31 -0400
> X-Mailer:  Microsoft Exchange Server Internet Mail Connector Version 4.0.993.5
> Mime-Version: 1.0
> Content-Type: multipart/mixed; boundary="---- =_NextPart_000_01BC57C9.66EAACF0"
> 
> This message is in MIME format. Since your mail reader does not understand
> this format, some or all of this message may not be legible.
> 
> ------ =_NextPart_000_01BC57C9.66EAACF0
> Content-Type: text/plain; charset="us-ascii"
> Content-Transfer-Encoding: 7bit
> 
> Mr. moore,
> 
> 	I sent tapes to Digital at Nashua, N. H., here is copy of the note I
> included:
> 
>  
> This will explain what I sent them. If they need any more information
> let me
> know.
> 
> 	We have a couple of other problems I'd like you to take a look
> at. These problems have occured fairly frequently, but just getting
> around to 
> documenting them. They are descried in the following attachments:
> 
>     
> Any help with these would be greatly appreciated.
> 
> 
> 					Thanks
> 							Sam
> 
> ------ =_NextPart_000_01BC57C9.66EAACF0
> Content-Type: text/plain; name="Mltm.txt"
> Content-Transfer-Encoding: quoted-printable
> 
> Barbara,
> I promised Martin Moore I'd send an mltape of the files that are causing =
> an ACL
> problem and memory allocation error. I's taken a while but here they =
> are.=20
> 
> Enclosed are 3 tapes. The ones marked ace7 and ace8 are mltape backups =
> of 2 seperate disk. When I attempt to backup both disks with the =
> statement:
> 
> mltape -ovO /dev/rmt0h -F "/ace7 /ace8 -print"
> 
> I get the following error messages
> 
> Unrecognized ACL
> Unrecognized ACL
> Unrecognized ACL
> Unrecognized ACL
> Unrecognized ACL
> Unrecognized ACL
> Unrecognized ACL
> Unrecognized ACL
> Unrecognized ACL
> Unrecognized ACL
> Unrecognized information label
> Unrecognized ACL
> Memory allocation error
> 
> I can back the 2 disks seperately with the following commands:
> 
> mltape -ovO /dev/rmt0h -F "/ace7  -print"
> mltape -ovO /dev/rmt0h -F "/ace8 -print"
> 
> without error.
> 
> I was able to reload both of these tapes to the same disk, but when I =
> try to backup this disk I get the same error.
> 
> 
> Also included is an mltape backup of the NIS server. This has our =
> Encodings file, yp passwd, and yp group files. This may help in =
> determining the problem.
> 
> I would appreciate any help you can give us with this problem.
> 
> 
> 					Sam
> 
> 
> 
> 
> =1A
> ------ =_NextPart_000_01BC57C9.66EAACF0
> Content-Type: text/plain; name="Nfsto.txt"
> Content-Transfer-Encoding: 7bit
> 
>    On an otherwise idle system, (root was the only 
> one logged on any node.) the following command was issued on host 
> sebastian:
> 
>  ls -sR | sort
> 
> this resulted in the message:
> 
> NFS Slookup failed for server bashful: RPC: Timed out
> ./ace1/accplib/NOS/PF/CYBER/IRWD2 not found
> 
> I then logged on to the host bashful and entered the following:
> 
>  cd /ace1/accplib/NOS/PF/CYBER
> lsacl IRWD2
> 
> which resulted in this output:
> # file:IRWD2
> # owner:accplib
> # group:users
> user::rwx
> mask::rwx
> user:rtdr:r--
> user:tlcsrll:r--
> user:tlrcwah:r--
> user:tlrcfwp:r--
> user:tlrcelh:r--
> user:tlruwah:r--
> user:tlruelh:r--
> user:tlrcfts:r--
> user:tlruhab:r--
> 
> group::rwx
> group:rtdr:r--
> group:tlrcfts:r--
> 
> other::r-x
> 
> I subsequently entered this on sebastian:
> 
> ls -sR ./ace1/accplib/NOS/PF/CYBER/IRWD2
> 
> with this result:
> 
> 7 ./ace1/accplib/NOS/PF/CYBER/IRWD2
> 
>    If this were an isolated incident, we would not be concerned, 
> but this happens fequently, sometimes on systems that are busy, 
> sometimes on systems that don't appear to have much of a load.
>  
>    We would appreciate any sugestions and/or fixes to prevent this 
> problem.
> 
> 
> 					Sam
> 
> 
> 
> ------ =_NextPart_000_01BC57C9.66EAACF0
> Content-Type: text/plain; name="Nfsacl.txt"
> Content-Transfer-Encoding: 7bit
> 
>    We occasionaly get files from other MLS+ systems via mltape backup tapes.
> These systems have the same users defined (passwd file, group file, etc.).
> They also have a few other additional users defined that we don't. Sometimes
> the files have ACL entries for user indexes that are not defined on our
> system. When this occurs users will get an IO error when accessing these 
> files from nfs. They do not get an error if accessing the file from the 
> machine that is serving the disk. To correct this we log into the machine
> serving the disk, find the errant acl with lsacl and remove them.
>  Since ufs can handle acl's user indexes that don't have corresponding 
> user names, why can't nfs.
> 						Sam
> 
> 
> 
> ------ =_NextPart_000_01BC57C9.66EAACF0--
> 


- -- 
Martin J. Moore				5555 Windward Parkway West
Digital UNIX Support			Alpharetta GA  30201-7407
Digital Equipment Corporation		1-800-354-9000 x31679
[email protected]			DECATL::MARTIN
    

From:	KAMLIA::thomson "Barbara Thomson UEG Engineering  15-May-1997 1114" 15-MAY-1997 11:20:11.88
To:	Martin Moore <[email protected]>
CC:	smurf::bat
Subj:	Re: Patrick's problems 


	Hi Martin -- Let Sam know I did get his tapes and printout
	(but it is nice to have it on-line), and say thanks for the
	third tape, too.

	An engineer now has them in his hot little hands and is working 
	on it.  Mark will contact Sam directly if he has questions.

	As far as his other two questions go, i.e.,:

	(1) NFS timeouts and how to stop them from happening
	(2) NFS and handling unrecognized UID/GIDs and how to 
		stop them from happening

	I do not know offhand -- it will take some research.  I'll extract
	them and post them separately in the notes file, so we can track
	them.

	Thanks Martin!
	BAT

    

    Martin, Janet:
    
    Is the customer running patch kit level #9 with the mltape patch?
    Did they de-install the patch kit level #10?  Did they try re-building
    (tnet_mkdb) their TNETDB with patch kit level #10 or not?  Did it or
    did it not fix their NFS performance problem?
    
    Thanks
    BAT

    Major Sam Major sent me tapes which I gave to Mark May, who found the
    bug and created a fix.  I sent his mltape as a test patch to  him via
    [email protected] address given me by Phil Becker.
    
    (If it works, we should send him back his tapes.)

    Sam got the patch this morning and is testing it at this time.
    I'll let you know the results.  He said that he would indeed like
    the tapes back. :)
    
    Martin

          <<< SMURF::DISK$NOTES:[NOTES$LIBRARY]DEC_MLS_PLUS.NOTE;1 >>>
                               -< dec_mls_plus >-
================================================================================
Note 506.7          PAFB: why can't NFS handle unknown UIDs?              7 of 7
RHETT::AMAN                                           7 lines   3-JUN-1997 16:05
                              -< patch fixed it! >-
--------------------------------------------------------------------------------
    I just spoke with the customer.  He recieved a patched copy of mltape
    (that someone at PAFB got from Barbara, he thinks).  Anyway, he
    installed the patch and that has resolved the problem!
    
    Thanks for the work and fast attention to this customer issue!
    janet
    
    

    Thanks -- we'll send his tapes back then.
    
    P.S.  RE: "fast attention": Well, once we got the tapes and Mark got on
    the problem, it went fast... but remember this came in at the end of
    March... 2 months is *ahem* not so fast... :-(