Thanks for all the help, we finally find a temporary solution to our pbm. We

suspected that it is a bug in NIS+ (in particular the keyserv which cannot

release file descriptor after resolving user). We add 'ulimit = 256' before

we start keyserv in the /etc/init.d/rpc. (We haven't had time to test out

other values yet, this value can support at least 60 users).

To summarise, check list for supporting a number of remote logins:

1. The /etc/system should have

        set maxusers=<nnn>

        set npty=<nnn>

        set pt_cnt=<nnn>

2. In /etc/init.d/rpc add

        ulimit = <nnn>

   before starting the keyserv unless a patch has released to fix this.

Thanks to:

        rwolf@dretor.dciem.dnd.ca

        cip@us.oracle.com

        aidan@cse.unsw.edu.au

        steve@cegelecproj.co.uk

        don@mars.dgrc.doc.ca

        pva@nova.gmi.edu

And, fromaidan@cse.unsw.edu.au

; Just a guess....

;

; Can you do a

;

; # nismatch some_login passwd.org_dir

;

; as root on your 690MP, or does it come back with *NP* in the encrypted

; password field? Also, can you run "keylogin", or does it fail with

; a complaint that it can't contact keyserv?

;

; If nismatch and keylogin don't work, try doing a "truss" on keyserv.

; On my system it had a file descriptor leak. "truss" will show keyserv

; attempting to open various files and open() returning with EMFILE -- ie

; no more file descriptors. Reads to that file descriptor then fail with

; EBADF.

;

; What happens is that /bin/login is setuid root, and can't read the

; encrypted password field -- causing it to respond with "login

; incorrect" all the time. Sun has a preliminary (ie unreleased) patch

; for this problem patch id: T101620-01. You'll need to contact your

; software support people to get it.

; Applying it solved most of my problems.

Thanks

Peter Mok

SA, Computer Centre

City Polytechnic of Hong Kong.