HELP!!!!! Password file has been gzipped

[Mike Keys]

I ran a command to perform some gzip operations. Apparently, I didn't have my path set properly when it started running and it looks like the passwd file might have become gzipped.

I can't login with any username or passwd.
We backup using fbackups.

Am I going to have to restore from fbackup?

Is there a way to backdoor the passwd file so I can perform gunzip on it?

[Pete Randall · Accepted solution]

Hopefully you still have someone that's logged in - use that session to su to root and try gunzip'ing. If that doesn't work, you could try re-booting in single user mode, but I would be very concerned that you still would be unable to log in. I would say that your safest be it to frecover the passwd file but once again, you'll need to have a session already logged in.


Pete

[Rick Garland]

This is a good situation for Ignite as well. If you do not have a session logged in and cannot login via single user mode, then an Ignite restore is an option. Can be a tape or via the network.

[Fabian Briseño]

HI Mike.
i think you will have to restore from the fbackup, or if you have an ignite backup you could try to restore it from there, of course the second option will take longer.

[A. Clay Stephenson]

I hate it when these stupid computers do just what they are told to do. First, get a baseball bat and whack yourself 4 times. Next, knock the machine down (you may literally have to yank the power cord or TOC the box) and bring the system up in single-user mode by interrupting the boot process.

boot pri
Interact with IPL/ISL? Y
hpux -is

This will bring you up in single user-mode as root so you can perform maintenance. You will have to mount /usr and /var manually and an fsck will probably be required for each of those. You can then copy /usr/newconfig/etc/passwd to /etc/passwd which will restore a minimal password file with null passwords or you can restore your /etc/passwd file using frecover.

In the worst case, you may have to boot from your recovery media.

[Mike Keys]

nobody else is logged in. the server uses a web app that maintains its own username/password file. users are logged into the app and not the unix level. hence, the users are still running. the problem would be if we had to reboot or service the box.

i'm thinking i'm going to need to restore from ignite and then restore from last night's backup.

[James R. Ferguson]

Hi Mike:

I think your choices depend upon the damage done. You can boot into single user mode and use '/sbin/frecover'. An Ignite recovery is also an option as Rick suggests.

A very helpful practice when running a command that can be disasterous if you're in the wrong directory is to operate thusly:

# cd /path && rm *.log

...now, if '/path' isn't valid, you won't end up removing "*.log" files (in this example) in the last directory you were in!

It's also very good practice to configure root's HOME directory to be something *other than* "/". I like to use '/root'. This too affords another measure of protection for you.

Regards!

...JRF...

[Pete Randall]

The more I think about it, rebooting in single user mode should work, since you're automatically logged in as root with no need to enter a password so the passwd file shouldn't even be referenced. From there you can frecover or whatever.


Pete

[Mike Keys]

how about if i reboot into single-user mode and then run 'frecover -r' from last night's backup?

i'm afraid that there might have been other files affected by the gzip command.

[James R. Ferguson]

Hi (again) Mike:

Personally, if you are going to use 'frecover' I'd be selective about what I recover until I was sure of what I needed. Build a graph or use include/exclude arguments. Don't be hasty and potentially make matters worse.

Regards!

...JRF...

[Fabian Briseño]

I also think that single user is the way to go, you just boot into single user and you can mount all the filesystems and just don an uncompress on the file or recover from fbackup

[A. Clay Stephenson]

You will almost certainly need to manually fsck before being able to mount anything but rather than blindly doing an frecover, I would think that it would make more sense to hunt around on the system first. It's possible that you could do even more damage from the frecover. Bear in mind, it should be easy to find all of your gzipped files and if you have /usr mounted then you should be able to gunzip 'em.

[DCE]

An added note - if you are concerned about other files being potentially gzipped - run a find command in single user mode after all of the file systems are mounted

find / -name *.gz

Then build your frecover graph file from that list

Good Luck
Dave

[Mike Keys]

Here's a thought.

I have a SPARE rp2470 box specifically for this system. Everything is identical to the production box.

I was going to ignite this and restore with frecover to this box.

I rebooted from the ignite tape and it is coming up with an fupdate to run. Is this normal? The spare box never had an OS loaded and the PDC may not be up to date. If this is the case, will Ignite update the PDC first before restoring?

[Mike Keys]

I don't know what files were gzipped.

When I try to telnet to the box, the session starts and is immediately killed. At first, I was getting the login prompt, but I don't even get that anymore.

I tried running the ignite tape I used on this sytem for our spare box, just to see if I could restore. I kept getting an 'bad LIF magic' error, even after I cleaned the drive 2 or 3 times. (DAT DDS-4)

Hopefully, the frestore will work.

[A. Clay Stephenson]

The find command should find all the files that end in .gz although the example cited above has a flaw:

find / -name *.gz

should be:
find / -name '*.gz' so that find rather than the shell will correctly handle '*'.

and I would add 1 more filter since you are looking for regular files:

find / -type f -name '*.gz'

and if you know your bad work was limited to /etc then change the "/" to "/etc".

[Mike Keys]

Unzipped files after rebooting in single-user mode. Thanks for all of your help.