Pavel Epifanov wrote:
> I have done the same lately on /usr. Very funny.
>
> The possible solutions as I can see are:
>
> = if you have a backup - restore it. Preferred way I afraid. Did not work
> for me because daily potato upgrades.
>
> = if you have Tripware installed - there is a check for permissions as well.
> Does not work for me as well because reason above (very frequent updates).
>
> = Using existed Tripware database and perl/bash script to recover
> permissions only. Occasionally I have no time to find out the format
> of Tripware database and make script. Have someone done it already ?
>
> = The way I am going to use - reinstall Potato as soon as it will
> be released. It should be OK for my test computer. And it also
> remove a lot of garbage from dpkg/apt status file.
>
> Please correct me if I missed one way.
------------------------------------------------------------------------
Since this box was pretty thouroughly screwed, I decided to experiment
with it's system. I got several suggestions, one of them from George
Swan, shown below, was partially successful in restoring the system to
working order. I was also able to log in as root and manually change the
ownership of the main system directories back to root. As soon as I had
these system commands working, I upgraded to potato, even though it has
some pretty rough sections at present. It seems to have cleaned up most
of the problems, everything is working now including all of my
non-debian stuff such as StarOffice, Wordperfect, and several others. I
did check and a few of the /etc/dev files were also changed to the
correct ownership. I do NOT think all of them were changed back to their
original installation state. Since everything is running OK I will
continue to use this box as my test site. I have converted my former
test site to a full production system as it did not have any problems.
Feel free to check back with me if you have other questions.
> George Swan wrote:
> >
> > On Mon, 24 Jan 2000, John Foster wrote:
> >
> > Well, the following would be a start:
> >
> > awk -F: '
> > {
> > user = $1
> > group = $4
> > home = $6
> > }
> > home ~ /^\/home\// {
> > cmd = sprintf( "chown -R %s:%s
%s", user, group, home )
> > system( cmd )
> > }
> > ' /etc/passwd
> >
> > Of course you would have to be root first.
>
EXPLANATION OF SCRIPT:
It is an awk program. Everything between the quotes
is an awk
program. You see the awk on the first line? Well it
has three
arguments. The first one is " -F: ", the second one
is the program
between the quotes, and the third one is "
/etc/passwd ".
/etc/passwd is your password file. The original
design of UNIX was
that the password file would be universally readable.
Lots of
programs read it to discover what a user's real name
is. The
passwords are encrypted, which used to be secure.
Nowadays most
systems keep the actual password in an unreadable
file /etc/shadow,
byt the file is still called the password file.
It contains one entry per user and each user's
description has seven
fields. The first field is the user's login name.
The 2nd field is
their password. The 3rd field is your numeric user
id. This is what
is stored in a file's inode, not your name. The
fourth field is your
default group id number. There will be a
corresponding name for this
number in /etc/group. Each file's inode also
contains a group id.
But not necessarily the default one. The 5th field,
historically was
the GECOS field. On original Bell Labs UNIX systems
it contained the
user's password for their honeywell GECOS account.
Used if they were
printing on the GECOS printer, or submitting a batch
job to the GECOS
system. Nowadays it is divided up into sub-fields
that contain the
user's name, office number, phone number and so on.
The 6th field
contains the user's home directory. And the 7th
field contains their
default login shell.
So the awk program opens the password file. For
every line it assigns
three variables, "user", "group", and "home". That
is the stuff
between the first pair of braces. The stuff between
the second set of
braces only gets executed conditionally. The
variable "home" has to
match a regular expression. It has to start with
"/home". On UNIX not
every user in the password file is a real human
being. Some are
"daemons". Daemons do regular, lower priority system
tasks. They sit
around all the time, wake up, check to see if there
is anything for
them to do, and then go to sleep. When a daemon
doesn't need to be
run as root, it typically used to be run as the user
daemon. But then
some daemons, like uucp, got userids of their own.
This script is
only supposed to change the ownership of the files in
the home
directories of real live users.
Which brings us the stuff between the 2nd pair of
braces. sprintf
builds a string, called cmd, which contains a command
line. The "%s"
in the format strings get replaced by the values in
"user", "group"
and "home", so the cmd for me would become,
"chmod -R geo:1009 /home/geo".
The system() function forks a new shell to execute a
command line.
This should fix 99.x% of your user's files. Of
course user's might
have the original hard links to one another's files.
If you had hacked
a version of telnet let's say, and I had a hard link
to it, because ot
the way inodes work this script couldn't tell who was
supposed to be
the owner, and so the file's ownership would be
changed once for every
link to it. But that information was already lost.
--
AdVance-Computing Systems
We sell fine quality servers and workstations.
We specialize in multiprocessor units.
We install Debian Linux at no extra charge!
John Foster
[EMAIL PROTECTED]
ICQ# 19460173
