brendan@world.std.com (Brendan P Kehoe) (08/07/90)
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@cs.widener.edu | temp: brendan@world.std.com Also: brendan@chinet.chi.il.us | Preferred: bkehoe@widener.bitnet