UNIX for Dummies Questions & Answers

One of our VM machines mysteriously went read-only overnight and as it wasn't being used, thought it would be a good idea to reboot the machine and run fsck on boot, well. . . .. things didn't quite work out that way lol

Anyway, the machine booted up, but mysteriously had no hostname set, thought I would check why and the '/etc/host' file is missing, checked further and it turns out that the 'init.d' folder and ALL the init scripts are missing too, as is 'xinet.d', and probably a host of other files from '/etc'.

Although we have backups, I need to try and get the machine back onto the network so I can copy the files back over . . . . . . question is, is there any way that I can start the network back up without the init scripts ?

Tried the usuals, ifup etc all to no avail - any of you brilliant minds out there any ideas !?

Cheers, Jim

You will have to be more specific about 'all the usuals', and especially specific about what you actually did with them, we're pretty much in the dark here. Especially since you didn't tell us what your OS actually is. ifup makes me suspect it's Linux, and if so, you can try giving your system a wholly manual configuration like this:

Code:

ifconfig eth0 192.168.0.50 255.255.255.0
route add default gw 192.168.0.1
echo nameserver 192.168.0.1 >> /etc/resolv.conf

...assuming you want it to be on 192.168.0.50 with a gateway of 192.168.0.1 and a DNS server of 192.168.0.1. If you know the IP addresses of everything DNS is optional.

We've had a similar problem where an archiving job was failing in the batch with a permissions issue. We changed it to run as root forgetting that it meant a different home directory and therefore an input file was not found. The knock on effect meant that we managed to move /dev, /etc, /opt ...... into an archive area. Very difficult to recover because you could not start a new session (/etc/passwd was not there of course) but with luck someone had a session as root that we could manipulate enough to recover, putting back /etc & /dev first and we could get more people logged on to investigte and restore.

The upshot is that your incident won't have happened by bad luck, sunspots or whatever, there has been an action taken to remove things. It may have been a mis-typed command, or an ill designed batch job where a small change has had catastrophic consequences.

Depending how paranoid your auditing is, you may have logged something, maybe not. We were able to work out what it was based on the time batch jobs started failing to start and the jobs already running, so we got lucky. We also had a bootable image on DVD to restore from if necessary.

Whilst you may be able to recover (or go to your full restore/DR plan) you need to determine what happened to prevent a recurrence.


Robin
Liverpool/Blackburn
UK