Following is a summary of the responses I got concerning my post about
a week ago abou some problems I was having with logins hanging now
that I have C2 security installed.
The original posting was as follows:
>I'm having an intermittent problem (more often than not) during login
>after implementing Sun's C2 Security on the few machines that I'm
>trying it on.
>
>Machine info:
> SunOS4.1.1
> Sparc 1+, Sparc 2
> NOT running NIS/YP
> Using BIND libraries for resolving
>
>Problem Description:
> Sometimes after making a mistake during {login,rlogin,telnet}
> to one of the machines I've got Sun's C2 security implemented,
> the machine just hangs after entering the password. The mistake
> can be in either the userid or password field. The login itself
> is hanging. I can go into the machine and kill the login.
>
> Has anyone run into this problem? Is there a patch for C2? My
> main use of the C2 security would be for the use of passwd.adjunct
> and group.adjunct.
>
----- end of original post -----
My solution:
Chad A. Bersche (cab3@engr.uark.edu) had the answer closest
to what I was needing to do. Since my main reason for C2 was
for the {passwd,group}.adjunct [a.k.a. shadow passwording] and
not so much the auditing (even though I would like to use that
as necessary), I told the C2conv script not to audit anything
and proceeded to give no space for auditing records (I'd add
this at a later time).
The catch was that even though I told it not to record any
audit records, it still wanted to find a filesystem to write
to when there were invalid logins made. In other words, even
though I told it not to audit anything, it still wants to record
a little information. Since there was no where to write to,
an invalid login would just hang there.
My solution after thinking and thinking was to give in and give
a little space for auditing records. Mr.Bersche's solution was
to not start up auditd in /etc/rc.local. I also did this with
good results.
My final set up was to set minimal auditing into a small partition
and leave auditd running. As I need to, I adjust what I want to
trail with the auditing.
A few people pointed me to patch 100201. This wasn't exactly
the fix I needed but it did fix a different problem I had noticed
in my attempts to fix the real problem.
--- Cornell Kinderknecht
Following are edited versions of the responses I got:
#1)
One problem springs to mind. By any chance, are the nameservers down when
these login failures occur -- or, more likely, the Ethernet link to same?
What *could* be happening is that the Sun is attempting to resolve the name
of the host from which you are making the login attempt for logging purposes.
The timeout on these searches can be pretty long when they fail... and if you
have three possible nameservers in /etc/resolv.conf, that's three times the
delay!
I used to have a problem along the above lines when I had special code in
place for my Sun to log *all* login attempts. If the link to our nameservers
was down, login would seemingly take forever. I solved the problem by putting
a copy of the files needed by named on "warper", then turning "warper" into
a nameserver in its own right.
#2)
There's a patch. I believe it's number 100201 and it is definately
available via anonymous ftp from ftp.uu.net.
#3) (The award-winning solution)
We were having a very similar problem here on some (but not all) of our Sun
systems ranging from several IPC's to all of our Sparc II's. When we got the
latest Sparc II in, we decided that we'd re-install the OS from ground zero to
see if we could locate the problem. After each stage of the installation we
would stop and check to see if everything still worked as it should. The
problem was not in the OS (well, depends how you want to look at it, I
suppose), but rather in C2. After we ran the C2 convert, the problems started
up. We had gone thru the C2 installation and told it to go ahead and allow
X% of disk space for the audit files, and such, but we had no intention of
starting auditing at the time. Right after we ran the convert we tried to log
into it. The first login after a re-boot was always successful. Any
subsequent logins were not. We felt we had nailed it down to a problem with
C2. It ends up that after we disabled the auditd the problems vanished.
Needless to say after messing with this for about 2 months trying everything we
could think of, it was a great relief to get it fixed.
I'm not sure if the "bug" lies in C2 not appreciating it if you tell it to set
up auditing, but then don't do it, or if it's a problem with login trying to
give the information to C2 and it not wanting it. Either way, by diabling the
auditd our problems simply no longer exist.
#4)
Try patch 100201-03, available in sun-dist on uunet. It seems to have
cleared up the problem for us.
#5)
Look for Patch-ID# 100201-03 (C2 jumbo patch). It fixed my problems with
password adjunct files.
#6) (Another from Mr.Bersche)
Basically the problem probably arose when we didn't give it a place to store
the auditing information (drive space is too precious here, so we didn't want
to waste it on audit info). So we tend to think that since we didn't tell
it where to put the audit info (not even a /dev/null) when the audit deamon
decided to write something, it got confused as to how to write it out to
nowhere and would lock up the system. Then we just took it out of the
rc.local file and didn't let it start up the audit deamons.
This archive was generated by hypermail 2.1.2 : Fri Sep 28 2001 - 23:06:20 CDT