Daring to challenge the will of the almighty Leviam00se, Julian Bean
: When I was fiddling with my passwds file the other day (I know - dangerous
: pasttime) I decided to change the root shell from csh to tcsh. Accidentally, I
: typed /sbin/tcsh rather than /bin/tcsh, and when I rebooted, of course, it
: didn't let me log in (no shell).
Even if you had typed it correctly, this is a bad idea unless you managed
to compile a static version of tcsh (which is hard to do and not supported
by Sun). /sbin/sh is the only statically linked shell on the whole system,
which means its the only shell you can use in single user mode (i.e. when
/usr isn't mounted and there are no shared libraries available). If you
had tried to actually use a dynamically linked tcsh in single user mode,
you would have gotten nothing but errors saying that libc.so (or maybe
even ld.so) could not be found. You might not have even been able to boot
multi-user correctly anymore.
As much as root's default shell sucks, resist the urge to change it. It's
more trouble than it's worth.
: Logging in as another user didn't help, as we have only one super-user, and
: 'su' won't let you 'su' to a user without a shell.
A-yep.
: "No problem", I thought, "I'll reboot into single user mode. Surely that will
: automatically override /etc/passwd and use a bourne shell".
A-nope. Used to be that was the default in SunOS. Not so in Solaris. Sun
decided to have Solaris default to 'all security turned on by default' mode
as opposed to 'all security turned off by default' mode in SunOS. You'll
find that root is also only allowed to log in directly on the console,
and that you have to explicitly create an /etc/hosts.equiv file in order
for rsh to work as expected. (SunOS used to have a default /etc/hosts.equiv
file with only a '+' in it. *shudder*)
: So, I hit L1-A at
: a login prompt, and did a boot -s. No luck. It booted into single user mode,
: asked for a password (for system maintanence), but then said 'su: no shell',
: and booted back into init level 3. Cheers. 'boot -as' was no better.
A-yep.
: I actually solved the problem by plugging in our CD-ROM, putting in my Sol 2.4
: master, and doing a boot cdrom. When it asked for some config information, I
: ignored it, brought up a command shell, and used vi to reconstruct /etc/passwd.
: This seems like a security hole to me, but heck - our office is secure anyway.
The idea is that the system console is supposed to be in a secure location
where only authorized personel have access to it. But this was back when
the machine was a huge metal monster locked in a refrigerated room
somewhere. Desktop UNIX systems have made things much more complicated.
However, as you pointed out, since your office is 'secure,' meaning that
only authorized office workers are supposed to be there (and presumeably
you have some means of keeping unauthorized people out), the risks are
about the same as they were in the days of big iron. Except that now
it's easier for someone to physically steal the machine without herniating
themselves. Or spill coffee on it.
: But what was I supposed to do?
Exactly what you did. In fact I commend you for keeping your cool
and reasoning your way to the solution without asking for help on this
newsgroup. :) The only sure way to recover from a problem like this, no
matter what flavor of UNIX is involved, is to boot the system from your
installation media, which should have enough tools on it to access the
filesystem on the system disk, and get to the shell. Being able to boot
straight off the CD is actually a luxury: in some cases you have to do
arcane things like load a miniroot system into the swap partition from
tape or boot from floppy (or even several floppies). There are variations
to this (booting the machine over the network or taking the system disk
out and attaching it to another working machine that can read the root
filesystem properly) but they all involve having superuser access to
another running system. Presumeably, your installation media is kept
in a nice safe (and secure) place by your system administrator so that
not everybody can grab it and break into their workstations whenever they
want. You could also set the PROM password to prevent unauthorized reboots,
but then you have to be ultra sure you don't lose the password or your
machine is hosed.
: I was sure that boot -s would automatically use
: /bin/sh.
Unfortunately, that would cause trouble for places that have workstations
available for general use, such as university computer labs. Students would
have a field day.
-Bill
--
=============================================================================
-Bill Paul (212) 854-6020 | System Manager
=============================================================================
License error: The license for this .sig file has expired. You must obtain
a new license key before any more witty phrases will appear in this space.
=============================================================================
by