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, from aidan@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.
This archive was generated by hypermail 2.1.2 : Fri Sep 28 2001 - 23:08:58 CDT