chown -R xyxname:users run from / !!!

[S.N.S]

Well,

With power comes responsibility -->

One of the Users with "rootly" powers run from / the command

chown -R xyxname:users

and now I dont know which all dir under / have their file ownership changed!

What is the best possible damage control step(s) that I can take at the earliest??

Need your advices very soon!

No replies wont go unrewarded :-)

Dunke/Merci
SNS

[Horia Chirculescu · Accepted solution]

Hello,

-R just aggravated the situation.

You have a problem now...

If you can, you should restore the system from ignite backup.

A lot of problems will arouse from bad settings in the ownership of the directories/files.

>and now I dont know which all dir under / have their file ownership changed!

If you (or your user who did it...) did not forced interruption of the chown process, all the files have ownership changed. Only newly created files snd directories would have the owner as imposed by the creation process.

Best regards,
Horia.

[Robert-Jan Goossens]

Hi SNS,

# swverify -F \*

Above will fix all permissions, ownership and date stamp on all installed (swinstall) software.

For the rest of data and apps/db's you probably need to take a look at you backup.

Regards,
Robert-Jan

[Kapil Jha]

Question is where this command is run

chown -R xyxname:users

if its under /

everything is gone the only thing u can do is recover from backup, or if its small server and u have little information then u may try to fix major file systems and then fix the things slowlu slowly.

BR,
Kapil+

[S.N.S]

Its what I exactly feared!

Is there no way else?
Or rather - do I have to restore the whole server?
Or can I do a recursive copy of / from the Ignite tape -- I dont think so, but surely hope for it!

More points coming on the way for valuable suggestions

Dunke
SNS

[Horia Chirculescu]

You should follow the path Robert-Jan Goossens underlined.

Fix the installed (using swverify as suggested) applications and for the rest of the software you must make some time for it. It is a hard job to do but will keep the existing changes (between the backup and current time)

I would take an ignite backup of the current server and then will restore the server and applications/data from the oldest backup I have. Then I will restore data from the newly created ignite backup in another directory using pax in order not to overwrite the ownership/whatever of the files. Then cp will overwrite the files recovered from latest backup..

A lot of work to do...

Horia.

[S.N.S]

Sorry,

There is no way except full restorerom tape - it was done from / and all files are affected

Out of curiousity, would it ever have been possible to trace the changes - however so numerous - after such a devastating -R option?

Dunke
SNS

[Horia Chirculescu]

>would it ever have been possible to trace the changes

There is no automation mechanism that will get you an option of undoing those actions.

You could periodically save somewhere (in a file) all the files ownership and then you could re-staurate the ownership if something would be bad. You could write 2 scripts for this, one that will create the file with the file names and ownerships and the second for restoring the information when needed)

But in practice this is not used as it is an nonstandard procedure (for a strange situation).

Horia.

[Robert-Jan Goossens]

Hi,

Did you try running the swverify command?

If the swverify fails, change the owner:group of swverify first.

$ ll /usr/sbin/swverify
-r-sr-xr-x 11 root bin 2478080 Feb 16 2007 /usr/sbin/swverify

Regards,
Robert-Jan

[S.N.S]

Robert & Horia, and all,

The swverify worked-thanks

The only application running is Oracle - that too clustered on the shared VG, ie SAN...

No other applications running on the vg00- the only VG on this server

So just to doubly confirm - I just have to recover from this Disaster from
1. Ignite Backup ---- Am I correct?

Thank a mil,
SNS

[S.N.S]

To be clearer:

1.No applications running on the Server - the server is a part of a two node cluster

2. Only application running - Oracle - is on the SAN

3. Latest Ingite backup dated 6th April


So, purely, only the OS need to be restored - and nothing else.
I can directly go the the Ignite restore - I dont see any issues - Am I correct?

Kindly advice if I am mistaken.

Dunke
SNS

[Dennis Handly]

>I just have to recover from this Disaster from Ignite Backup - Am I correct?

It depends on how much programming/scripting you want to do. Your data is all there, it's just the ownership that's wrong.

If you can get the ownership off of ignite and your other backups, you can just do chowns.

[Horia Chirculescu]

>The swverify worked-thanks

This is a start...

>No other applications running on the vg00- the only VG on this server

And this is good for you.

I believe you should check first the errors from alert.log. If by any chance you do not have any, you can continue with the instance/application up...

I would restore data from the newest ignite backup in another directory in order not to overwrite the files, then change the file ownership on the installation directory according to those.


Horia.

[S.N.S]

Hi Dennis,

Is that a very intensive process?
And can it be fully done with scripts?

I am not aware - is there any script in handy? If yes, that would simply be great!

Hoping for the best,
SNS

[Horia Chirculescu]

>1.No applications running on the Server - the server is a part of a two node cluster

You have a clustered environment. This is good.

2. Only application running - Oracle - is on the SAN

Do you mean the ORACLE instance/package was up on this node or only the application? Maybe both of the packages were running on this very same node?

>vg00- the only VG on this server

If this is a clustered environm., are you sure that you do not have also another VG?

Horia.

[S.N.S]

Horia,

>>then change the file ownership on the installation directory according to those.

There are many recursive files - how best to go about to change each dir?

Merci
SNS

[Horia Chirculescu]

>- how best to go about to change each dir

Use the recursive (-R) option.

Or you could write a script that first would read the owner/group for each file from the ignite backup then restore those on your actual server.

But in case of ORACLE instance and application things should be easier because the ownership is the same (or maybe with only a few exceptions which must be threated individually) on all files from the top directory. So chown -R should be fine.

Horia.

[Dennis Handly]

>Is that a very intensive process? And can it be fully done with scripts?

If you have a cluster, you can read the ownership from one machine and apply to the other.

>is there any script in handy?

See my scripts in:
http://forums.itrc.hp.com/service/forums/questionanswer.do?threadId=1215123

>There are many recursive files - how best to go about to change each dir?

If the ownership is all the same, that's easy. :-)

[S.N.S]

Thanks for that again folks - Dennis and Horia...

And by the only VG on the server >>
There is only one VG - vg00 on the server;
other VGs pertain to the SAN - all related to cluster VG, and VGs for Oracle -
in recovery terms - no related application data on the server..

I look up the script from the linl - thanks!
I am taking a backup of the server as we speak...

Thanks all for your valuable advice...
Will update You, and then close the post-[ no points before the update :-)..]

Merci
SNS

[Bill Hassell]

>> One of the Users with "rootly" powers run from / the command

So you have changed the root password and will not give it to novice user ever again, correct? If you don't have sudo installed, that is strongly recommended so that your helpers will be restricted as to the damage they can cause.

>> run from /

Where is root's $HOME directory? If you made the mistake of leaving it in /, then this type of catastrophe will happen again and again. HP (and most other Unix vendors) still put root's home in / -- the worst possible location. To avoid future damage like this, move root's home directory (and root's files) to something like /root.

[S.N.S]

Yes,

I need to do that -- the Servers had multiple problems when I took over ; so was concentrating on them.

Some basic things to be checked and done.

Thanks again for your inputs,
Appreciate your time.

Will Update on the issue in 2days.

Dunke
SNS

[Benoy Daniel]

try to run a find command and can findout which are the files got modified recently. This may able to help you..

find -ctime

True if the time of last change of file status information subtracted from the initialization time is n-1 to n multiples of 24 h.

[Horia Chirculescu]

Hello,

>other VGs pertain to the SAN - all related to cluster VG, and VGs for Oracle -
in recovery terms - no related application data on the server..

My point was this: if the VGs that contain LUNs from SAN (at SAN level, only LUNs are 'known') were actually mounted on the very same node when your user run the chown command, then the ownership of those files are also modified! So you need to check those files also.

Of course, no harm was done if the volumes were unmounted at that time.

Best regards,
Horia.

[S.N.S]

Hi,

Horia, unfortunately shared VGs are on the same node...

Best to run the script - right?

And yes, Benoy, there are more the 4700 file permissions changed..

Will update you all
Dunke
SNS