Conference turris::digital_unix

I'm not sure what the problem is, but if the /dev files were changed with the
rest of the system, you may have caused lots of problems. Here are some things
to check:

srwxrwxrwx   1 root     system         0 Feb 24 16:31 /dev/printer

In each spool queue:

-rw-rw----   1 daemon   system       154 Feb 12 11:43 cfA130msdazy.zk3.dec.com
-rw-rw----   1 root     system      3844 Feb 12 11:43 dfA130msdazy.zk3.dec.com
-rw-r--r--   1 root     system         5 Feb 24 16:26 lock
-rw-rw-r--   1 root     system        71 Feb 24 16:26 status

(the first two are examples of a queue file)

An error log file:

-rw-r--r--   1 daemon   daemon         0 Oct 16  1995 /usr/adm/lperr

And when you get these things fixed, a reboot would be a good idea, if you
think
you have fixed enough for it to succeed.

The message of most importance is the one that says "bind: Address already in
use". This means that lpd can not bind to the network socket which would
connect
it to remote lpd's and printers. You may have hung an lpd with the changes
that
you made which is still around and holding ontothe socket. A reboot would fix
this.

Rich Hart.





[Posted by WWW Notes gateway]

Use fverify to check file permissions and ownerships.

PJDM

The first chmod lost all of the setuid/gid sticky bits.

As just suggested use fverify with fix.
The -y is not usually a good idea but since every file has been affected
the result can not be much worse than it is now. Since the machine has been
up and running esp in a UNI environment with 777 down the tree I would not have
much confidence in the state of security even after running fverify, But this
is a start. They may want to copy the *.inv files from the various CD kits
directories to /usr/.smdb. and rerun the fverify script again this will confirm
that the .inv files have not been fixed to cover other changes. All local
scripts and binaries should then be checked all mount points all checksum
missmatches in the log should be reviewed and replaced . If students have
been any where near this machine while it is wide open then I'm pretty sure
that they will have abused it. Take it off the net before starting the
validation. You will need to get a fresh copy of fverify nothing can be trusted!
If the machine is V4.x at least the CD will be a good source of valid unpacked
binaries. As a further thought if the  machine is 4.x boot from the v4.x CD
get single user  mount the system tree as /root /root/usr /root/var as per
the current fstab run the second script fixcd.sh. Its not pretty nor guarenteed!
It will try and validated kits that are not installed just ignore them. I have
not tried this from the cd fverify will want to log to /var so other problems
may arise. If there is any chance that the system can be restored from backup
then they should do this. I realy hope this is a small unimportant workstation:)


	Cheers
		mark :)
ps.
	Would have been ok with fverify if now one had been near the system
now its its really stuffed.

	GOOD LUCK!


#!/bin/ksh
# fix.sh
# important fverify must be run from root dir
#
cd /

for i in /usr/.smdb./*.lk
do
s=${i%%.lk}
/usr/lbin/fverify -y < $s.inv
done


#!/sbin/sh
# fixcd.sh
#
CDROOT="/"
ROOTMNT="/root"
#
cd $ROOTMNT

for s in $CDROOT/instctrl/*.inv
do
$CDROOT/usr/lbin/fverify -y < $s
done

    My customer once did a chmod to 000 for every file on the system. That
    knocked execute off all commands, including chmod!
    
    The only way we could figure to recover this one was total restore from
    tape.