Default Shell in /etc/passwd is bad

[kozlow]

I have a non-existing shell (bad name) for root in my /etc/passwd file.

I have a good copy of the passwd file (from the original server) on another server.

Is there anyway to get it over to the server and overlay.

I can not rlogin, telnet, FTP, rsh......

Any Ideas?

The only way I can figure on getting around this is to Boot in Single User Mode... I am in Georgia and the Server is in St. Louis....

 

[SamBones]

Can you log in using another account and [tt]su[/tt] to root?

I would boot to the Solaris installation disk, then drop out to a shell, mount the system's root disk, then edit the file. These are the same steps as resetting root's password when you don't have it. This FAQ has the steps...

http://www.tek-tips.com/faqs.cfm?fid=1568

Hope this helps.

 

[kozlow]

$ su
Password:
su: No shell


The problem with booting in single user mode is that you have to be on-site... I am in GA and it is in St. Louis....

 

[kHz]

Is this an AIX server or Solaris server?

You posted the same exact question in the AIX forum.

Same thing I answered in AIX. Do you have a jumpstart server?

 

[KenCunningham]

Can you put the good passwd on tape and try to restore on the other server. That said, will probably not work due to permissions I guess. Do you have assistance at the St Louis end?

 

[kozlow]

I found you can do an:
exec login UID envior....

So I tried
exec login root SHELL="/usr/bin/ksh"

Turns out you can change every other but your default shell.

Looked at the doc, but to change init level you would have to be root....

Thanks anyway.

 

[comtec17]

Follow the tip SamBones gives in the link

http://www.tek-tips.com/faqs.cfm?fid=1568

 

[kHz]

He still never answered whether it's AIX or Solaris.

 

[kozlow]

I have HP-UX, SUN, LINIX and AIX... And they are at different OS levels.

UNIX is UNIX...

In this case it is a SunFire 280R running SUN OS 5.8

 

[KenCunningham]

Then it's Solaris. 'Unix' might be 'Unix' in the ideal original concept, but there have been many and varied divergences since then which make all the difference when trying to recommend a course of action.

 

[kozlow]

Got you...

If you go to the AIX forum, they came up with some great thoughts....

I have been told by many UNIX guru's, there is never just one way to solve a problem. Live and learn... Take what works best for you...

Thanks for all the help. Found many ideas that really had me thinking.

As of now, I am still at "You can't get there from here".

 

[KenCunningham]

I have been told by many UNIX guru's, there is never just one way to solve a problem. Live and learn... Take what works best for you...

Good advice that is too, there's amost always more than one way to skin a cat in unix of all descriptions, that's part of the attraction. Unfortunately, as you say, you're hitting a wall here, despite everyone's best efforts. Perhaps the best option is a 'plane to St Louis with a CD or to find a contractor there to go in and sort the problem - shouldn't be more than an hour's job!

 

[kozlow]

I ordered a new set of OS CDs from SUN and shipping them directly to the site...

Going to see if I can walk our NT support on-site through it.

The most fun is when I show him "vi".

Thanks again.

 

[KenCunningham]

Yes, should be fun! Good luck - you could do worse than emailing your NT folks a copy of the FAQ from this forum dealing with the issue.

 

[PJONJACK]

Solaris is truly it's own UNIX, the root users shell is optimized and apparently has some weird hardwiring into their kernel. I had this same thing happen to me and ended up reinstalling because we couldn't get back in to fix the file.
I am hunting down this obscure reference that I found which basically says 'NEVER CHANGE THE ROOT USER SHELL ON SOLARIS'. It's in a Solaris doc or SunSolve posting which I know I kept so when I dig it up I'll post it here.

 

[WhiteVolg]

Koz, tell me you have sudo installed and I can solve this problem without console access, otherwise, it's 'boot cd -s' time.

 

[kozlow]

I am looking at taking some old backups that where doing using a product called dataprotector.

If I can scan the tapes back into the database, I may be able to come up with an old version on the passwd file.

I hope that I can run a restore...

Let you know if it happens.

 

[KenCunningham]

WhiteVolg, first of all welcome to the Forum, you have obviously been very active in your first couple of days!! I'm sure we'd all be interested in your sudo solution, whether or not kozlow has it installed or not. TIA.

 

[bfitzmai]

I did't think a sudo user could modify the /etc/passwd file.

 

[WhiteVolg]

Assuming you have sudo installed your administrators can sudo to root, 'sudo -s' bypasses the /etc/passwd shell definition, instead using the shell from which it was called to open a new shell. I, being a fat fingered type, have been rescued by this feature a number of times. Thus it is good practice in such a situation to
A) never log in as root (I commonly have a password unacceptable to login, but useable by sulogin for root. Preventing direct login to root in multiuser mode other than through su or sudo.)
B) Always have at least one administrator account which can sudo to root.
C) Never give anyone other than the systems administrators the root password or any other 'group account' password.

As to bfitzmai's response. Yes they can if they can sudo to root.