/etc overwrite

[Jeff Hagstrom]

I had a question about /etc/fstab a little while ago and it was answered, thank you, but I did not realize the big problem.

Yesterday, our /etc directory was over written from another box(identical and both running 11.00). Initially I was having a problem getting into SAM(error: 7159, sam.log saying that the filesystem isn't mounted). Realized that the fstab was overwritten, semi-fixed that, but there are other things that I need to look for that I don't know about.

Example: /etc/rc.config.d/netconf IP address and hostname needed to be changed. What else is out there that could bite me in the you know where? Presently I can not connect to the HP box from my PC when I use the correct IP address. However, if I login to our production box and rlogin to the test box(the one with the problem), it will allow me to login.

[Santosh Nair_1]

As for the telnetting problem, looks like you IP/default route is screwed up.

As for losing /etc...geeze :-)

The few critical files that I can think of are the following:

/etc/fstab
/etc/hosts
/etc/sudoers
/etc/shells
/etc/passwd
/etc/profile
/etc/group
/etc/nsswitch.conf
/etc/resolv.conf

And you'll have to recreate /etc/lvmtab (using vgscan) and hopefully you didn't have any printers defined because they might be lost (they should be in /etc/lp).

-Santosh

[Patrick Wallek]

/etc/ was overwritter? Oh boy!

You do have a backup of your system don't you? Perhaps an Ignite/UX make_tape_recovery tape? I would be tempted to restore /etc from whatever form of backup you have.

[A. Clay Stephenson]

Hi Jeff:
This is not meant to be a complete list but here goes:

/etc/passwd
/etc/group
/etc/hosts
/etc/hosts.equiv
/etc/inetd.conf
/etc/services
/etc/lvmrc
/etc/lvmtab ---> really serious
/etc/fstab
/etc/mnttab
/etc/rc.config.d/*
/etc/nsswitch.conf
if running DNS server: /etc/named.data/*
if a ServiceGuard Node: /etc/cmcluster/*

If it were me, I would restore from backup to /etc2 and then do a cksum on each file and copy the file into /etc if needed.

P.S. Don't do this no more!

Regards, Clay

[linuxfan]

Hi Jeff,


The best thing would be to recover it from a a backup.

If that is not an option you will have to atleast update/recreate the following files (AFAIK)
hosts
passwd
group
nsswitch.conf
resolv.conf
fstab (recreate)
lvmtab (recreate)
rc.config.d is a directory which contains config files which get sourced during startup, you will have to check if everything is ok there
/etc/cmcluster - MC/SG if you use service guard
ntp.conf - for NTP
mail - (/etc/mail contains all your sendmail config/aliases, not sure if you updated any but if you did, you will make sure you make those changes)

Some of the sample files are available in /usr/newconfig/etc, you can copy them and modify them.

As far as recreating the /etc/lvmtab is concerned , you could do a vgscan -p -v (man vgscan) and if everything is ok run vgscan -v which would recreate the lvmtab file.

You definitely will have to update /etc/rc.config.d/netconf and modify the ip address and the hostname.

I may have missed some, but i still think the better option is to do a restore.

-HTH
Ramesh

[Bernie Vande Griend]

Santosh has a good list.
Also, check the rest of /etc/rc.config.d/netconf, especially the route information. Do a netstat -nr to check the routes on your server to make sure they are correct. Otherwise you probably need to edit netconf some more.

[Sachin Patel]

Hi jeff
Before you reboot your system make sure your external disk configuration is OK.

run set_parms command and change IP, hostname networks etc..
#set_parms initial (This will reboot your system)

When system will comeup you will have more work to do
/etc/nsswitch.conf, resolv.conf, named.conf, and much more.

Just to change a IP address
#vi /etc/rc.config.d/netconf (change information regarding ip and route)
#/sbin/rc2.d/S340net stop
#/sbin/rc2.d/S340net start

Sachin

[A. Clay Stephenson]

Hi again:

The more I think about this, I think your best bet is to restore from backup in single user mode. If you are using Omniback or some other utility that requires you to be in a higher run level, I would restore to an alternate directory and then go to single user. I would then mv /etc /etc/.old and mv /etc2 /etc and reboot.

Regards and good luck, Clay

[linuxfan]

Hi Jeff,

Check your /etc/inetd.conf file.

Also you may have to recreate the /etc/lvmconf directory, because it now contains information about the VGs from the other machine.

for i in $(ls -1d /dev/vg*)
do
vgcfgbackup $i
done

-Regards
Ramesh

[James R. Ferguson · Accepted solution]

Hi Jeff:

Since this is a test box that has the problem, I'd get my Ignite recovery tape and cold-install it; if nothing else it's good practice.

I think otherwise you may spend more time correcting and verifying key configuration files than this is worth. Consider that you will need to be relatively positive that you have a correct configuration before you boot, not only from the standpoint of a network configuration, but from the standpoint of LVM when volume groups are first activated and filesystems are first mounted.

At least, this was a test server!

Regards!

...JRF...

[Santosh Nair_1]

James is right...you're probably better off just re-igniting/re-installing the server than trying to restore and reconstruct all the files that were damaged. There are far too many thinks to worry about, i.e. getting all the file and then making sure the permissions are right, etc. that its probably just better to start from scratch.

-Santosh