Mário Barbosa wrote:
> sudo chown -R <someuser>:<somegroup> /
> ... and then came back to me for help.

Oh my goodness!

> I'm a sysadmin on the RH/CentOS camp, and my confort level with
> apt-* and dpkg* is extremely low.
> 
> Is there anything like "rpm -V" on the debian toolset? I'm trying to
> avoid "punishing him" (further) with reinstall...

Because this is ownership and permissions I don't think there is a
completely trivial solution.  There is 'debsums'.  But that won't be
sufficient since it is looking specifically at file content.  And I
saw the other suggestions.  I would NOT have done a dpkg -Gi on the
archives directory.

(I may have done an apt-get install --reinstall on a list of packages
that were installed on the system, a list from dpkg -l | awk
'{print$2}'.  But that would blow up the apt extended_states file and
marked everything as manually installed.  See 'man apt-mark'.  Would
have saved it off before and restored it aftward.
  cp /var/lib/apt/extended_states /root/
  apt-get install --reinstall $(dpkg -l | awk '{print$2}')
  cp /root/extended_states /var/lib/apt/
You get the idea.
)

Here is what I would have done.  If I were wanting to "save" the
system rather than install again.

I assume the system is very unhappy.  I would mount the disk on a
different good system and save it from there.  Otherwise I would work
across two systems.  Reset the values from the known good to the
mangled.

I would generate a list of files on the mangled system.  Avoid all of
the tmpfs and proc filesystems.  Then I would do the same on the host
system or a different known good similar system used as a reference.
Then I would find the common set of files between the two.  I would
see what ownership and permissions lived on the good system for those
files and generate a script to set the mangled system to the same.  I
would just do it on the fly on the command line using grep and sort
and awk and comm and those types of things.

Of course that is where the work is done but I would scramble around
and convert 'stat' output into commands to reproduce the ownership and
permissions.

  xargs stat --printf "chown %U %n\n" < filelist > cmdfile

That will be broken for any files with whitespace in it but the system
doesn't have any of those.  Inspect for whitespace and scrape those
out and handle manually.  Then do the same for permissions.  And so
forth.  Craft the script to restore the ownership and permissions.
Then run the script!

Be careful not to break the host system with an absolute path to the
target system!  (I did that once so am speaking from experience.
D'oh!)  That should get 90% of everything back into good shape again.
Use a good reference system to determine what ownership and permission
the mangled system should have.

That will still leave some files that are installed on the mangled
system that do not have known good info from the reference system.
Take that list and run it through 'dlocate'.  The dlocate command is a
fast indexed 'dpkg -S' command.  You will likely need to 'apt-get
install dlocate' to have it but it is so much faster than 'dpkg -S'
that it is very useful to install.

  xargs dlocate < filelist | awk '{print$1}' | sort -u >pkglist

That will produce a packge list of the files that you don't have
information for.  I would possibly install those on a test system just
to get the right ownerships and permissons for them.  I would install
in a VM and then throw the VM away afterward.  I create a lot of
throwaway VMs for testing things like this so for me that is natural.
But a real machine would be fine too.

Or probably for 99% of those files you would know immediately what
needs to be done by visual inspection and would just do the right
chown and chmod commands to fix it.  But at least by that time it
would be a much smaller list.  Then I would probably have done the
apt-get install --reinstall of every installed package as discussed
above just to be as safe as possible.

I know this probably isn't helpful now at this late date.  But that
type of thing is the way I would have attacked the problem.  There
isn't any canonically right answer.  At some point everyone just uses
their best judgement and muddles through these problems as best as
they can.

Bob

Attachment: signature.asc
Description: Digital signature

Reply via email to