1

One of the sys admins accidentally moved aside /etc/passwd... doh! Restoring the file from backup doesn't work... it errors out because root user does not exist.

I've got NIS running at this site and serving the passwd/group/shadow files and I tried to add a root user but I can't get this to propogate (I tried different values for MINUID and MINGID). I understand why NIS would want to avoid doing such a thing, but, errrm, HELP!

The server is running CentOS 5.6 and it doesn't have a CD/DVD drive so I can't reboot onto a rescue CD.

Any suggestions?

Caroline
  • 13
  • 2
  • 1
    Have you the ability to boot it remotely via an .ISO file as you can on most HP servers via iLO or Dell via DRAC? – Chopper3 Aug 22 '11 at 10:50
  • Hell, PXE boot the thing into a rescue environment. However you got the OS installed in the first place, you can use that same method to get a rescue environment. – womble Aug 22 '11 at 11:04

2 Answers2

1

I'm sure there is some way to try shoehorning the root user onto it, but if you're desperate to get it working again in a minimal timeframe my method of getting it to work would be a USB thumbdrive or USB CD-drive that you can boot from with a rescue CD; either of these should be readily available and by the time you find a way to use a clever workaround you probably could have been back from the local retailer with the drive and the download of a rescue distro waiting at your desktop.

You don't mention more information on the server but there's a possibility that it's not running RAID (or the system drive isn't RAIDED)? If that's the case you can remove the drive and mount it in another system and alter the file there. Depending on how critical the system is you can try mounting the drive and controller in another system to bring the whole RAID volume up as another drive.

You might want to consider getting the USB drive as a backup to your recovery process for that server in the future. Your problems may be human error this time but that doesn't preclude drive corruption in the future causing similar issues.

Bart Silverstrim
  • 31,092
  • 9
  • 65
  • 87
  • I was hoping to avoid rebooting the server as it is a production machine. But also this server (IBM System X 3650) has 2 megaraid controllers and the BIOS was a nasty piece of work - there is a problem with it such that it had to be cajoled/hacked into seeing the root partition on the local disk. So frankly I am not that confident that once I am on a rescue CD, the BIOS will be able to recognise (and allow me to mount) the local root partition. And I am also concerned that if there is no root UID, would the machine even be able to boot again? So I would like to try the NIS hacking if possible. – Caroline Aug 22 '11 at 11:11
  • Womble suggested PXE boot if it supported it, which could work too but assumes you have an environment set up to do so (or you will need to take time to get that working), or you would have to look at what security fixes are available but not applied to your server to "break" into it. If your backups are truly truly up to date you could find some filesystem gurus to try getting raw disk access, if you have a user with permissions to edit the raw drive and try restoring the file with a hex editor...but if it's RAIDed there's not way I'd ever consider it more than a nanosecond. – Bart Silverstrim Aug 22 '11 at 11:15
  • How would you have planned to restore the system from backup otherwise? It should have some way of booting to restore from bare metal; it may allow a selective restore from a boot environment as well. – Bart Silverstrim Aug 22 '11 at 11:16
  • (I know you don't want to reboot it, but if you're trying to hot-fix it in untested ways, you're risking your data and system integrity in the process; a half-hour of downtime from a reboot/restore is probably better than a day of downtime from a goofed MacGuyverism on the filesystem, especially if you're in panic mode and may overlook something in the process) – Bart Silverstrim Aug 22 '11 at 11:18
  • I did install with PXE boot/kickstart, and the root drive is mirrored. But what you guys don't know is that this BIOS is about as friendly as a hungry alligator. If I reboot, I am not sure I will be able to recover in a reasonable time (hell it took 2 weeks working with IBM to get an OS installed, I have never met such a broken BIOS before). NIS is already serving passwd/group/shadow information, it *has* to be able to serve a 0 UID somehow... Then again maybe I don't have any other option but to wrestle with the alligator. Thanks for all your help with this I very much appreciate it! – Caroline Aug 22 '11 at 12:46
  • sorry unrelated, but you seem to be an expert. would you mind viewing my question? https://serverfault.com/questions/905235/nis-password-map-root-user – n00b Mar 29 '18 at 17:18
0

You might try temporarily editing the NIS Makefile on the NIS master server. Where it currently says

passwd.byname: $(PASSWD) $(SHADOW) $(YPDIR)/Makefile
        @echo "Updating $@..."
        @$(UMASK); \
        $(MERGER) -p $(PASSWD) $(SHADOW) | \
           $(AWK) -F: '!/^[-+#]/ { if ($$1 != "" && $$3 >= $(MINUID) && $$3 !=$(NFSNOBODYUID)) \
           print $$1"\t"$$0 }' | $(DBLOAD) -i $(PASSWD) \
                -o $(YPMAPDIR)/$@ - $@
        -@$(NOPUSH) || $(YPPUSH) -d $(DOMAIN) $@

try changing that awk line to remove the tests for MINUID and NFSNOBODYUID, eg

           $(AWK) -F: '!/^[-+#]/ { if ("" == "") \

and similarly in the section for passwd.byuid, remake the passwd maps, and see if the root entry is now in there with ypcat passwd.

MadHatter
  • 78,442
  • 20
  • 178
  • 229
  • Nice try! But unfortunately I get an error which I can't figure out how to fix: Updating passwd.byname... /bin/sh: -c: line 1: syntax error: unexpected end of file gmake[1]: *** [passwd.byname] Error 2 gmake[1]: Leaving directory `/var/yp/nis.cambridge.scr.slb.com' make: *** [target] Error 2 – Caroline Aug 22 '11 at 12:50
  • sorry unrelated, but you seem to be an expert. would you mind viewing my question? https://serverfault.com/questions/905235/nis-password-map-root-user – n00b Mar 29 '18 at 17:18