At Wit's End

[Brendan P Kehoe]

Ever have some problems that, after what seems *forever*, just seem to
never go away?  I've called Sun about all of the problems I'm going to
mention at least once; since I have a full 9-5 job *outside* of this, it
creates a massive problem for their support people (e.g. a software
support guy was supposed to come out last week, on Thursday; I arranged to
have him get the superuser password & have our other lab manager here to
help. The guy never showed, called, nothing.). So you can imagine what
kinda mood this has put me in.  I'm hoping (read: praying) that this post
will glean some answers from those who've seen or experienced what I have
(I'm certain, after the length of time that 4.0.3's been out, that at
least *one* person on this continent has had some of the same
experiences).  First, our setup is a SS1 as a server to a SS1 diskless
client. We are running 4.0.3, YP is up, we're also using Sunlink DNI 6.0
(along with dnimail [the one from Sun w/ all the fixes]). The entire CPU
and frame buffer have been replaced inside the diskless client.  Onward.
First, it is impossible to bring auditing up on the client. C2conv works
just fine. The audit_control file is:

dir:/usr/security/shirley
minfree:20
flags:ad,lo,p0,p1

Full C2 is up on the server with no hitches (save one..later). Whenever
auditd starts on the client, it seems to go into an infinite loop,
creating audit trails by the dozen. If I have it enabled to send mail when
there's trouble, the process table of the server gets filled with Sendmail
requests from the client. Here's a piece of the output of auditd -d:

auditd: Effective uid is: 9
auditd: Real uid is:      0
auditd: Loading audit list from /usr/security/audit_control
Directory list:
/usr/security/shirley
auditd: new minfree: 0
auditd: inside process_audit
auditd: checking /usr/security/shirley for space limit 0
auditd: bavail = 91617, minblocks = 0
auditd: inside open_log for dir /usr/security/shirley
auditd: inside getauditdate
auditd: auditdate = 19900805223526
auditd: inside close_log
auditd: Posting 1212, /usr/security/shirley/19900805223526.not_terminated.shirley to /usr/security/audit_data
auditd: Log opened: /usr/security/shirley/19900805223526.not_terminated.shirley
auditd: Begin audit service with /usr/security/shirley/19900805223526.not_terminated.shirley; limit = 0 blocks.
auditd: checking /usr/security/shirley for space limit 2
auditd: bavail = 91617, minblocks = 0
auditd: Error ignored: No such file or directory
auditd: calling /usr/etc/audit_warn with soft /usr/security/shirley/19900805223526.not_terminated.shirley 0
auditd: inside process_audit

And it goes on with this, incrementing the # (19900805223526) each time,
creating dozens of audit trails. The guy at Sun said there's no log of a
bug that looks like the 'Error ignored: No such file or directory'.  Oh,
/usr/security/shirley is 0700 owned by audit, group audit (in case yer
wondering).

Another thing that may be related -- when ypbind comes up on the server,
it says "ypbind: SunOS 3.x servers rejected". The Sun guy said it meant it
was trying to get a machine under 3.5 (we have only these 2 suns on the
network right now, for obvious reasons).

Still more...if I brought up the server then changed the status of
yppasswdd, the client's attempted logins would fail with 'clntudp_create:
RPC not registered'. By changing the status I mean I created an adjunct
file (our network passwords are in /etc/yppasswd), placed in
/etc/security/yppasswd.adjunct. (Yes, I adjusted the Makefile for the
changed location of /etc/yppasswd) Things worked fine on the server. If I
tried to log into the client immediately after changing the yppasswdd, it
would freeze right after I entered the username. IF, however, I logged in
as a user in the client's normal passwd file, then exited, then tried a
login of one of the network accounts, it would work fine only after I
rebooted the server, with yppasswdd starting up from /etc/rc.local. 

Well, the /etc/yppasswd and /etc/yppasswd.adjunct files work fine overall
now. Only one hitch. Whenever someone changes their password with
yppasswd, the permissions of /etc/security/yppasswd.adjunct change to 644.
OUCH! I'd set them to 0400, change the pw (telneting in) of a net account,
and slam, the file is as readable as can be, thus defeating my entire
purpose in creating the thing.

Well, that's the majority of what's been really p'ing me off lately. Any
and all help/suggestions/whatever would be welcomed with open arms.

Brendan Kehoe | Soon: brendan at cs.widener.edu | temp: brendan at world.std.com
Also: brendan at chinet.chi.il.us | Preferred: bkehoe at widener.bitnet