The best way may be to restore the old /etc/passwd and /etc/shadow from backup. When you deleted passwd.old you may have deleted your account information.
getent retrieves an item or items from a particular database such as /etc/passwd or /etc/networks and prints it to stdout. Did you do more that this? What was the source. For example, if you run "getent passwd" you could enter "sudo getent shadow" to get the shadow file entries from the same source. What is in /etc/passwd now. I wonder if you replaced /etc/passwd from another source but didn't replace the cooresponding shadow file. It is possible that someone manually edited /etc/passwd (instead of using usermod) in the past and made a backup first.
Look at "getent passwd" and "sudo getent shadow" from the same source and compare them with your current /etc/passwd and /etc/shadow.
To be able to login, you could reset the root passwd. Boot up with a rescue disk and mount the root partition.
Change the UID & GID to 0 as it should be, and zero the passwd entry in /etc/shadow.
[code]
/etc/passwd:
root:x:0:0:root:/root:/bin/bash
/etc/shadow:
root::13828::::::
[code]
Then reboot and try to login as root. If you can, run the "passwd" program to create a new passwd.
Then backup up the important project you mentioned.
System users will have entries like "news:x:9:13:news:/etc/news:" in /etc/passwd and "mail:*:13709:0:99999:7:::" in /etc/shadow. Note the "*". A system users account is disabled and doesn't have a passwd. I'm not certain if mail's uid and gid are fixed for a particular distro or are created when the system user is created. You could look at the gid of a directory you know is owned by the mail user.
Code:
sudo find ./ -group mail -exec ls -nd '{}' \;
drwx------ 2 0 12 4096 Nov 26 05:04 ./spool/mqueue
drwxrwxr-x 2 0 12 4096 Nov 26 05:04 ./spool/mail
-rw-rw---- 1 1000 12 0 Jul 15 07:12 ./spool/mail/jschiwal
Using another FC machine as a model, you may be able to reconstruct the /etc/passwd, /etc/shadow, and /etc/group system user entries. Especially if the UID & GID values are fixed. If not, you could look at the query listing of the rpm package giving you that service to find out what files or directories if any are owned by that service. Then examine the "ls -ln" listing of that file or "ls -lnd" listing of a directory to find out what the UID & GID values are.
Good Luck!
---
Just my 2 cents worth.
For a Fedora Core or Red Hat host, it may be better in the future to use a system-config program to change the authentication source in the future. You not only have to worry about samba & pam, but possibly have se_linux settings to contend with.
