Greetings again. We got the problem solved and got some good advice to
boot. Thanks to:
Root of all Evil <root_at_physics.umd.edu>
Joel_Gallun/US/DCI_at_discovery.com
Joana Peres <jperes_at_fe.up.pt>
Rich Lafferty <rich_at_alcor.concordia.ca>
We're fairly sure the tar (the correct invocation and not the one I
hurriedly listed in my original question):
cd dir; tar cf - . | (cd newdir; tar xf -)
got confused. Either it went to / (or /etc) on purpose or accident. The
result was the tar pipe spit files back out with changed permissions (no p
flag) and that's what did it. So far as we know, it was localized to
/etc. After changing a bunch of permissions from 600 to 644 in /etc,
things started working again. I think the best response I got was from
Rich, who (I'm paraphrasing and I adding the p flag) suggested using:
cd dir && tar cf - . | (cd newdir && tar xpf -)
I added some short notes after each of the answers listed here.
Thanks a million folks!
ORIGINAL QUESTION =====================================================
> The machine is running 4.0D and TCR - no yp but is running c2. the auth
> db seems to be fine (i.e. edauth works):
>
> We've got a production machine that recently may have had some files
> deleted (but she's not sure what ones) during a user update (a tar pipe of
> their files (cd dir; tar cf . - | (cd newdir; tar xf -)) files THEN
> REMOVE THE OLD COPY and remove their passwd entry). It may have been
> buggy code, because we're guessing it started to copy (tar) / right back
> to /. It may or may not have remove some files.
>
> Right after she noticed it tarring /, she stopped it, but the system has
> been screwy since, saying things like:
> Intruder Alert
> when a user types "whoami" (although root's whoami works fine). Other
> things that use user info (excepting "who") also fail, such "ls -al",
> which simply returns uid's.
>
> We've restored the passwd file from a pre-script backup, and permissions
> on /etc/passwd are right, but to no avail.
>
> Anyone got any ideas?
>
ANSWER ================================================================
Hola.
Firstly, this *isn't* the solution to your problem, but it might stop it
from occurring again.
> We've got a production machine that recently may have had some files
> deleted (but she's not sure what ones) during a user update (a tar pipe of
> their files (cd dir; tar cf . - | (cd newdir; tar xf -))
You mean:
cd dir && tar cf - . | (cd newdir && tar xf -)
What I suspect happened was that the 'cd newdir' failed, but nothing told
the tar to not happen. The && (logical AND) will prevent that.
ANSWER ================================================================
Hello!
Try to remove /etc/passwd.pag and /etc/passwd.dir. This password
databases may be aren't coerent with your passwd file.
You also can run vipw to create new passwd database files.
{tried all of those to no avail, but thanks! - ivo}
ANSWER ================================================================
use fveriify on your installed subsets to see which files are messed up and/or
missing.
ANSWER ================================================================
Not a real expert, but we've seen something similar. Our systems are AFS'ed,
and all login stuff goes through kerberos not passwd file. I have seen these
intruder alert messages when something went wrong with our automated passwd
file updates across systems that resulted in truncated passwd files. Seem to
get the intruder alert messages when your UID is not in /etc/passwd.
{that's what we thought, but the passwd file was completely intact, the
same as her before-script backup, etc. And her (and several other) entry
was fine. ??? we figured it was an /etc file somewhere that was causing
our problem to somehow LOOK like what your talking about. thanks - ivo}
=======================================================================
thanks,
_____________________________________________________________________________
Ian Veach, Systems Software Analyst, UCCSN Systems Computing Services
ivo_at_nevada.edu, VOICE: (702) 784.6486, FAX: (702) 784.1108
_____________________________________________________________________________
Received on Thu Jan 07 1999 - 17:03:43 NZDT