|
Home > Archive > Unix administration > August 2004 > "No Shell"
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
|
|
| Andrew McCallum 2004-03-09, 11:34 pm |
| Dear Sirs/Madams
1st:
I have read all the previous posts over the past ## years regarding
this problem.
Story:
I have (as smart as it is) altered the root shell in /etc/passwd.
I have booted in single user mode, mounted the / filesystem, and
changed the value to a shell that does exist. I have tried
/usr/bin/sh
/bin/sh
/usr/bin/csh
/bin/sh (got me into trouble in the first place)
no matter which shell I try, I get "No Shell" when trying to log in or
su root. Even though they all exist in /usr/bin.
I have scratched all the hair from my head.
Any suggestions appart from stupid "ftp from another server" are all
welcome.
Thanks
Andrew
andrewmccallumau@hotmail.com
| |
| Adam Price 2004-03-10, 2:34 am |
| On 9 Mar 2004 20:24:32 -0800, Andrew McCallum wrote:
> Dear Sirs/Madams
>
> 1st:
> I have read all the previous posts over the past ## years regarding
> this problem.
>
> Story:
> I have (as smart as it is) altered the root shell in /etc/passwd.
>
>
> I have booted in single user mode, mounted the / filesystem, and
> changed the value to a shell that does exist. I have tried
>
> /usr/bin/sh
> /bin/sh
> /usr/bin/csh
> /bin/sh (got me into trouble in the first place)
>
> no matter which shell I try, I get "No Shell" when trying to log in or
> su root. Even though they all exist in /usr/bin.
>
> I have scratched all the hair from my head.
>
> Any suggestions appart from stupid "ftp from another server" are all
> welcome.
>
> Thanks
>
> Andrew
> andrewmccallumau@hotmail.com
Which OS? What shell are you using in single user mode? Why not set it to
that?
Have you checked that you don't have strange characters embeded in your
passwd entry for root?
Try creating a completely new passwd entry for root.
If you can type su then I am assuming you have a functional login shell of
some kind. In which case copy the passwd file entry for the user who is
successfully logging in, then change the UID and GID to 0 and the name to
root. Make sure that this entry comes before the old one in the passwd
file.
Hope this helps
Adam
| |
| phn@icke-reklam.ipsec.nu 2004-03-10, 2:34 am |
| Andrew McCallum <andrewmccallumau@hotmail.com> wrote:
> Dear Sirs/Madams
> 1st:
> I have read all the previous posts over the past ## years regarding
> this problem.
> Story:
> I have (as smart as it is) altered the root shell in /etc/passwd.
> I have booted in single user mode, mounted the / filesystem, and
> changed the value to a shell that does exist. I have tried
> /usr/bin/sh
> /bin/sh
> /usr/bin/csh
> /bin/sh (got me into trouble in the first place)
> no matter which shell I try, I get "No Shell" when trying to log in or
> su root. Even though they all exist in /usr/bin.
> I have scratched all the hair from my head.
> Any suggestions appart from stupid "ftp from another server" are all
> welcome.
Change back the value of "shell" to your vendors selection.
Then go learn how you start another shell from command line or
via tools like sudo.
Moral : Dont ever change root's login-shell.
> Thanks
> Andrew
> andrewmccallumau@hotmail.com
--
Peter Håkanson
IPSec Sverige ( At Gothenburg Riverside )
Sorry about my e-mail address, but i'm trying to keep spam out,
remove "icke-reklam" if you feel for mailing me. Thanx.
| |
|
| check your shell script header such as:
#!/usr/bin/sh
Andrew McCallum wrote:
> Dear Sirs/Madams
>
> 1st:
> I have read all the previous posts over the past ## years regarding
> this problem.
>
> Story:
> I have (as smart as it is) altered the root shell in /etc/passwd.
>
>
> I have booted in single user mode, mounted the / filesystem, and
> changed the value to a shell that does exist. I have tried
>
> /usr/bin/sh
> /bin/sh
> /usr/bin/csh
> /bin/sh (got me into trouble in the first place)
>
> no matter which shell I try, I get "No Shell" when trying to log in or
> su root. Even though they all exist in /usr/bin.
>
> I have scratched all the hair from my head.
>
> Any suggestions appart from stupid "ftp from another server" are all
> welcome.
>
> Thanks
>
> Andrew
> andrewmccallumau@hotmail.com
| |
| Scott McMillan 2004-03-10, 9:35 am |
| On 9 Mar 2004 20:24:32 -0800, andrewmccallumau@hotmail.com (Andrew
McCallum) wrote:
>Dear Sirs/Madams
>
>1st:
>I have read all the previous posts over the past ## years regarding
>this problem.
>
>Story:
>I have (as smart as it is) altered the root shell in /etc/passwd.
>
>
>I have booted in single user mode, mounted the / filesystem, and
>changed the value to a shell that does exist. I have tried
>
>/usr/bin/sh
>/bin/sh
>/usr/bin/csh
>/bin/sh (got me into trouble in the first place)
>
>no matter which shell I try, I get "No Shell" when trying to log in or
>su root. Even though they all exist in /usr/bin.
>
>I have scratched all the hair from my head.
>
>Any suggestions appart from stupid "ftp from another server" are all
>welcome.
>
>Thanks
>
>Andrew
>andrewmccallumau@hotmail.com
Not sure if this applies in your (unnamed) flavor of *nix, but are the
shells you specified in /etc/shells?
Scott McMillan
| |
| hymie! 2004-03-10, 10:36 am |
| In our last episode, the evil Dr. Lacto had captured our hero,
andrewmccallumau@hotmail.com (Andrew McCallum), who said:
>Dear Sirs/Madams
>
>Story:
>I have (as smart as it is) altered the root shell in /etc/passwd.
>
>Any suggestions appart from stupid "ftp from another server" are all
>welcome.
It kinda sounds like you lost (or added) a : to the root line in /etc/passwd
hymie! http://www.smart.net/~hymowitz hymie@lactose.smart.net
========================================
=======================================
| |
| joe durusau 2004-03-10, 1:35 pm |
|
Andrew McCallum wrote:
> Dear Sirs/Madams
>
> 1st:
> I have read all the previous posts over the past ## years regarding
> this problem.
>
> Story:
> I have (as smart as it is) altered the root shell in /etc/passwd.
>
> I have booted in single user mode, mounted the / filesystem, and
> changed the value to a shell that does exist. I have tried
>
> /usr/bin/sh
> /bin/sh
> /usr/bin/csh
> /bin/sh (got me into trouble in the first place)
>
> no matter which shell I try, I get "No Shell" when trying to log in or
> su root. Even though they all exist in /usr/bin.
>
> I have scratched all the hair from my head.
>
> Any suggestions appart from stupid "ftp from another server" are all
> welcome.
>
> Thanks
>
> Andrew
> andrewmccallumau@hotmail.com
If you are talking about solaris, the root shell is generally
/sbin/sh.
Why didn't you use usermod to change the shell if you really had
a legitimate reason for doing so, (although personally I've never
had one nor heard of one existing)? It would have told you that
the shell in question did not exist.
Speaking only for myself,
Joe Durusau
| |
| Andrew McCallum 2004-03-10, 5:35 pm |
| Thanks all for the advice.
I was able to create a new root entry in /etc/passwd.
Unfortunately I had already tried changing the shell back to its original /bin/sh.
Anywho, thanks for the help.
I am no longer rooted (or am I)
Andrew McCallum
| |
| nospam 2004-03-10, 11:34 pm |
| in article c2me8v$ok3$1@nyheter.ipsec.se, phn@icke-reklam.ipsec.nu at
phn@icke-reklam.ipsec.nu wrote on 10/03/2004 17:57:
> Andrew McCallum <andrewmccallumau@hotmail.com> wrote:
>
> Moral : Dont ever change root's login-shell.
>
Moral : BS I change my root shells to /bin/ksh and will always do so.
On every OS I've run init has /bin/sh hardcoded into it. When getting into
single user it never looks at /etc/passwd to work out what todo!!!!!!!
What ever this person was doing it wasn't going wrong because they changed
/etc/passwd root shell! Probably /bin/sh was screwed up
Cheers
Mark
| |
| Michael Vilain 2004-03-11, 1:34 am |
| In article <BC761774.254AF%x@wedontwantyourspam.com>,
nospam <x@wedontwantyourspam.com> wrote:
> in article c2me8v$ok3$1@nyheter.ipsec.se, phn@icke-reklam.ipsec.nu at
> phn@icke-reklam.ipsec.nu wrote on 10/03/2004 17:57:
>
>
>
> Moral : BS I change my root shells to /bin/ksh and will always do so.
> On every OS I've run init has /bin/sh hardcoded into it. When getting into
> single user it never looks at /etc/passwd to work out what todo!!!!!!!
>
> What ever this person was doing it wasn't going wrong because they changed
> /etc/passwd root shell! Probably /bin/sh was screwed up
>
>
> Cheers
> Mark
>
You have to much time on your hands. And probably don't run things
except 'your way'. Well, that's fine as they _are_ your systems.
However, when you retire or get hit by a bus or are fired for being a
twit or just fade away into inrelevance, someone will have to piece
together the non-standard systems you leave behind or just reinstall
everything from scratch.
There's your argument for changing root's shell to whatever you want,
but you seem to have a clue. The OP didn't and got bit. For these
newbies, there's this:
http://www.cse.psu.edu/~groenvel/root-shell.html
You're welcome to scoff and do whatever you want, but you'll leave that
mess when you "move on", thereby causing all your sucessors' jobs to
that much harder, to curse your name and the spawn of your loins, and
generally have a low opinion of your skills which they can communicate
to future employers asking for references.
--
DeeDee, don't press that button! DeeDee! NO! Dee...
| |
| nospam 2004-03-11, 10:38 am |
| in article vilain-BB8B1C.22313710032004@comcast.ash.giganews.com, Michael
Vilain <vilain@spamcop.net> at wrote on 11/03/2004 17:31:
> In article <BC761774.254AF%x@wedontwantyourspam.com>,
> nospam <x@wedontwantyourspam.com> wrote:
>
>
> You have to much time on your hands. And probably don't run things
> except 'your way'. Well, that's fine as they _are_ your systems.
Bit hard to do it somebody any other way. Time on my hands not enough
> However, when you retire or get hit by a bus or are fired for being a
> twit or just fade away into inrelevance, someone will have to piece
I'm a bit over weight at the moment but fish I'm not ;)
> together the non-standard systems you leave behind or just reinstall
> everything from scratch.
If any of these events happen, if the only thing to worry about is the shell
named for root in /etc/passwd then I don't thing there is much for them to
worry about
>
> There's your argument for changing root's shell to whatever you want,
> but you seem to have a clue. The OP didn't and got bit. For these
> newbies, there's this:
>
For these newbies using solaris there's this:
> http://www.cse.psu.edu/~groenvel/root-shell.html
>
> You're welcome to scoff and do whatever you want, but you'll leave that
> mess when you "move on", thereby causing all your sucessors' jobs to
Maybe that's how you leave systems ;)
> that much harder, to curse your name and the spawn of your loins, and
> generally have a low opinion of your skills which they can communicate
> to future employers asking for references.
You logic seems a little wacky. The shell in /etc/passwd being changed has
very little too do with anything else on the system. This attitude seem to
be based on some bad shit happening with SUN OS's. Let me just say on Tru64,
MacOS-X/Darwin, Linux, NetBSD, and Ultrix, having the root shell as ksh
causes no harm and give me a decent command line editor/recall. It in no way
turn any of these systems into a unsupportable, non-standard (what ever
standard that maybe so many to choose from). What the rest of the system is
depend quite a bit on my experience and its done me quite well for the last
20+ years ;) not on the shell in /etc/passwd for the root user!
Do what ever you like but don't if you going to start urban myths about
roots shells based on one vendors OS. Say don't change the root shell on
solaris and leave it at that.
| |
| Michael Vilain 2004-03-11, 4:34 pm |
| In article <BC76BE27.255EC%x@wedontwantyourspam.com>,
nospam <x@wedontwantyourspam.com> wrote:
> in article vilain-BB8B1C.22313710032004@comcast.ash.giganews.com, Michael
> Vilain <vilain@spamcop.net> at wrote on 11/03/2004 17:31:
>
> Bit hard to do it somebody any other way. Time on my hands not enough
>
> I'm a bit over weight at the moment but fish I'm not ;)
>
> If any of these events happen, if the only thing to worry about is the shell
> named for root in /etc/passwd then I don't thing there is much for them to
> worry about
> For these newbies using solaris there's this:
Agreed. This entire discussion is because the OP did this on a version
of Solaris prior to Solaris 9. The problem is fixed on 9 and later (or
so I've heard).
>
> Maybe that's how you leave systems ;)
I try to leave systems with as much documentation and history so that
that whomever takes them over will only have to do a little reading to
find out when a GBIC was last swapped out or the tape drive was replaced
or memory was upgraded or when oracle was installed on the system.
I like standards. They create continuity, which was my point. Sun said
"Don't change root's shell" so I don't because it's easier to run my own
shell from the command line if I need root access. The manager at the
last site I was at wanted the shell to be ksh, but he knew what he was
doing and moved the shared libraries it needed into /lib on all the
Solaris systems. Seems more work to setup a system, but he was the boss.
>
>
> You logic seems a little wacky. The shell in /etc/passwd being changed has
> very little too do with anything else on the system. This attitude seem to
> be based on some bad shit happening with SUN OS's. Let me just say on Tru64,
> MacOS-X/Darwin, Linux, NetBSD, and Ultrix, having the root shell as ksh
> causes no harm and give me a decent command line editor/recall. It in no way
> turn any of these systems into a unsupportable, non-standard (what ever
> standard that maybe so many to choose from). What the rest of the system is
> depend quite a bit on my experience and its done me quite well for the last
> 20+ years ;) not on the shell in /etc/passwd for the root user!
>
> Do what ever you like but don't if you going to start urban myths about
> roots shells based on one vendors OS. Say don't change the root shell on
> solaris and leave it at that.
Agreed. I thought we were talking about Solaris only anyway.
Just as an aside, if you change HP/UX's root shell to anything other
than what HP set it to (I vaguely recall setting it to /sbin/ksh rather
than their braindead non-POSIX /sbin/sh), the system wouldn't shutdown.
The shutdown command said to change the shell back to /sbin/sh, then run
shutdown again. I did this on 10.20 some years ago and don't know about
11. What about AIX? Does it care? Is this a SYSV or BSD thing?
--
DeeDee, don't press that button! DeeDee! NO! Dee...
| |
| phn@icke-reklam.ipsec.nu 2004-03-12, 2:34 am |
| nospam <x@wedontwantyourspam.com> wrote:
> in article vilain-BB8B1C.22313710032004@comcast.ash.giganews.com, Michael
> Vilain <vilain@spamcop.net> at wrote on 11/03/2004 17:31:
> Bit hard to do it somebody any other way. Time on my hands not enough
> I'm a bit over weight at the moment but fish I'm not ;)
> If any of these events happen, if the only thing to worry about is the shell
> named for root in /etc/passwd then I don't thing there is much for them to
> worry about
> For these newbies using solaris there's this:
[color=darkred]
> Maybe that's how you leave systems ;)
[color=darkred]
> You logic seems a little wacky. The shell in /etc/passwd being changed has
> very little too do with anything else on the system. This attitude seem to
> be based on some bad shit happening with SUN OS's. Let me just say on Tru64,
> MacOS-X/Darwin, Linux, NetBSD, and Ultrix, having the root shell as ksh
> causes no harm and give me a decent command line editor/recall. It in no way
> turn any of these systems into a unsupportable, non-standard (what ever
> standard that maybe so many to choose from). What the rest of the system is
> depend quite a bit on my experience and its done me quite well for the last
> 20+ years ;) not on the shell in /etc/passwd for the root user!
> Do what ever you like but don't if you going to start urban myths about
> roots shells based on one vendors OS. Say don't change the root shell on
> solaris and leave it at that.
One of these days you will discover 'sudo', this will cure your tendency
to replace root's shell. There is simply no need to login as root - ever, login
as a "un-priviligied user" and sudo to whatever you need. As extra bonus
you don't have to guard(and spread) root's password anymore.
--
Peter Håkanson
IPSec Sverige ( At Gothenburg Riverside )
Sorry about my e-mail address, but i'm trying to keep spam out,
remove "icke-reklam" if you feel for mailing me. Thanx.
| |
| Jose R. Valverde 2004-03-12, 12:35 pm |
|
> One of these days you will discover 'sudo', this will cure your tendency
> to replace root's shell. There is simply no need to login as root - ever, login
> as a "un-priviligied user" and sudo to whatever you need. As extra bonus
> you don't have to guard(and spread) root's password anymore.
>
'Nuff nonsense.
In most UNIX systems the shell root uses has no relevance whatsoever.
Nor should it. If it does, it's the system fault, and no one else.
Root is just another user. The general phylosphy is that root can do
as s/he likes/needs. And change the shell or whatever it s/he just well damn
pleases (or needs to) is a part of it. That changes should be taken cautiously
is true, but they can and should be made.
There may be problems though, some of which are related to bad programming
and others to system maintenance. Any good sysadmin should know about them and
the correct workarounds. Saying sudo is the final solution is as well nonsense.
Much more imagining it will protect any password.
There are many reasons to taylor a system. What's important is that changes,
and their rational, are documented for successors to be able to take their own
decisions. There are not stone-cast laws in system administration, only
exceptions, workarounds and advice. It helps to go by the book when you
start, but the mark of a good professional is knowing when to bend the
rules to his/her advantage.
For more details:
- bad programming problems: if there are scripts that require sh but
do not use the #!/bin/sh magic, then changing root's shell to something
not sh-compatible will break them. Not that it matters much, after some
time one learns to use 'sh script' and it's fixed, or starts sh before
running them. Other than that nothing else should depend on root shell,
and if it does, it is badly designed
- it may be that the selected shell is not 'allowed', but then
changing the definition of allowed shells (e.g. /etc/shells) should do.
Or renaming the shell to sh
- sysadmin woes: if a program (the shell) is split among various
file systems and any of them breaks, you'll be in trouble. Solution:
trivial, place all pieces in the same file system or compile the
program statically. There's been argument whether anything root uses should
be dynamically linked at all, but that's probably moot today. Other than
that, which shell/program/script/tool you use should not matter.
- sudo and passwords: crap. Sudo is nice for what it was intended:
allowing users to run specific privileged commands. It won't protect any
password. Old timers may remember an attack in the early '90s on Suns that
would put them in promiscuous mode and grab the first N (200) chars of any
connection in the LAN. The typical sysman would login unprivileged and then
'su' to root, typing his/her password which would be in the grabbed buffer.
Any kay-punch-grabbing attack would do the same to sudo or any other.
- protecting passwords is and will always be a need and a must. Sorry
to bear bad news
- sysadmin WOES: pity the sysadmin who inherits a plain vanilla,
untouched system because his/her antecessor feared or dared not change
anything. Truth is, few of us look all the same or do the same thing, most
systems need tweaking and that's what we are paid for. An untouched system
has not been tailored, updated, upgraded, fixed... In short, it's a wreck.
So what? If a vulnerability in sh is reported, should it not be
changed to -say- a new version? If it may, what precludes anyone installing
an extended shell? Or another one instead? And if it is compatible, how will
the system tell? Why should it?
If the system requires specialized customization, are you to avoid it
because 'root' should not be touched? What is root there for then? If it were
an embedded system and instead of sh, another shell was needed, are you
going to tell to your boss 'uh, oh, that's a no-no'? To yourself? C'mon!
I've been using 'tcsh' as root shell for well over ten years now on
*BSD, Ultrix, OSF/1, Tru64, Irix, AIX, Linux, Sun/OS and Solaris (at least)
and always could manage the systems without any problem. I stomped on some
of the mentioned mistakes, but there always was a workaround and never
a real need for sh/ksh/csh/whatever. I still write most administration
scripts in 'sh' if you wonder about it, and switch over to sh or bash
for some specific tasks. For me that's being a pro: knowing my way around
well enough to make the systems work for me without a glitch.
Your successors only need that all changes be documented and their
rational explained. Even if it is a matter of personal preference. Much
more then, so they may change in the future to their needs. If they are
unable to read the documentation you leave behind, then they are not
suited to the position or you didn't write it correctly.
There are many reasons to change things in a system, that's what a
sysadmin is for. Spreading FUD is not professional. Explaining how to
work around problems and find solutions is.
j
--
These opinions are mine and only mine. Hey man, I saw them first!
José R. Valverde
De nada sirve la Inteligencia Artificial cuando falta la Natural
| |
| Tim Skirvin 2004-03-14, 12:35 pm |
| jr@cnb.uam.es (Jose R. Valverde) writes:
> - sudo and passwords: crap. Sudo is nice for what it was intended:
>allowing users to run specific privileged commands. It won't protect any
>password.
I don't agree. sudo allows you to cut the proliferation *and use*
of the actual root password. If sudo is used across the board, then the
worst that can happen is that the main root password can be changed, not
actually compromised (at least not by this alone).
It shouldn't be considered a cure-all, of course.
>Old timers may remember an attack in the early '90s on Suns that would
>put them in promiscuous mode and grab the first N (200) chars of any
>connection in the LAN. The typical sysman would login unprivileged and
>then 'su' to root, typing his/her password which would be in the grabbed
>buffer. Any kay-punch-grabbing attack would do the same to sudo or any
>other.
...but at least in this case they'd be grabbing the user's
password, not root's. This may be beneficial.
- Tim Skirvin (tskirvin@ks.uiuc.edu)
--
Theoretical and Computational http://www.ks.uiuc.edu/~tskirvin/
Biophysics, Beckman Institute, UIUC Senior Systems Administrator
| |
| Roger Marquis 2004-03-18, 9:45 am |
| nospam <x@wedontwantyourspam.com> wrote:
>Moral : BS I change my root shells to /bin/ksh and will always do so.
>On every OS I've run init has /bin/sh hardcoded into it. When getting into
>single user it never looks at /etc/passwd to work out what todo!!!!!!!
Same here. SH is a programming shell and not really useful for
command line use. I use tcsh myself, in all accounts and across
all operating systems, including many Solaris root accounts. Never
had a problem.
>What ever this person was doing it wasn't going wrong because they changed
>/etc/passwd root shell! Probably /bin/sh was screwed up
They probably made a simple formatting error, and could have avoided
that by using vi instead of usermod or vipw. (per
<http://www.roble.com/docs/sol_root_...#misconception1> ).
--
Roger Marquis
Roble Systems Consulting
http://www.roble.com/
| |
| Roger Marquis 2004-03-19, 11:36 am |
| Roger Marquis <not-for-mail@roble.com> wrote:
>They probably made a simple formatting error, and could have avoided
>that by using vi instead of usermod or vipw. (per
><http://www.roble.com/docs/sol_root_...#misconception1> ).
Er, ah, that should be: "could have avoided that by using usermod
or vipw instead of vi. Vipw is generally preferred because it is
cross-platform and works identically on most all Unix and Linux
systems. Solaris' vipw, however, has a bug that can cause problems
on large systems when a user changes their password at the same
time as an admin is running vipw. In those cases you're better off
with the usermod command despite its being Solaris-specific.
--
Roger Marquis
Roble Systems Consulting
http://www.roble.com/
| |
| David Douthitt 2004-05-19, 5:40 pm |
| "Michael Vilain <vilain@spamcop.net>" wrote:
> Just as an aside, if you change HP/UX's root shell to anything other
> than what HP set it to (I vaguely recall setting it to /sbin/ksh rather
> than their braindead non-POSIX /sbin/sh), the system wouldn't shutdown.
> The shutdown command said to change the shell back to /sbin/sh, then run
> shutdown again. I did this on 10.20 some years ago and don't know about
> 11.
I thought both HP-UX 10.20 and 11 used a POSIX sh. Trying to find the
Bourne shell on HP-UX is always fun (sigh).
I would have loved to switch our HP-UX systems to /bin/ksh but I didn't
know enough about the system to do such with impunity - I've heard
enough times the horror stories about not being able to log in and so
forth. When I start wanting more, I always just use the command
"/bin/ksh" and then continue on...
Linux is another matter - I know enough about Linux that I routinely
switch all root accounts to /bin/ksh. Only time it matters is if any of
the startup scripts use a "bash-ism" and don't remember to start their
script with "#!/bin/sh" ...
FreeBSD is yet another matter - I don't know if I could switch root's
shell without problems (their default is /bin/csh) but I don't have to.
There is a user "toor" which is also uid 0 included in FreeBSD for
just such a purpose - change the shell (for "toor" that is) all you
want, that's why "toor" is there.
| |
|
| On 2004-05-19, David Douthitt <ddouthitt@cuna.coop> wrote:
> Linux is another matter - I know enough about Linux that I routinely
> switch all root accounts to /bin/ksh. Only time it matters is if any of
> the startup scripts use a "bash-ism" and don't remember to start their
> script with "#!/bin/sh" ...
Which in itself is bad enough.
--
j p d (at) d s b (dot) t u d e l f t (dot) n l .
| |
| Kevin Collins 2004-05-19, 5:40 pm |
| In article <c8g42b$jmv$1@grandcanyon.binc.net>, David Douthitt wrote:
> "Michael Vilain <vilain@spamcop.net>" wrote:
>
>
> I thought both HP-UX 10.20 and 11 used a POSIX sh. Trying to find the
> Bourne shell on HP-UX is always fun (sigh).
They do - /sbin/sh is a POSIX sh, /usr/old/bin/sh is Bourne. And HP's /sbin/sh
shares the codebase with /usr/bin/ksh :
$ strings /sbin/sh | grep -i ksh
ksh: Cannot reset line disciplines
ksh: Cannot set line disciplines
ksh: sysconf error
ksh: no memory
And I can't think of anything offhand that can be done with ksh as a user shell
and not be done exactly the same way with /sbin/sh on HP-UX...
>
> I would have loved to switch our HP-UX systems to /bin/ksh but I didn't
> know enough about the system to do such with impunity - I've heard
> enough times the horror stories about not being able to log in and so
> forth. When I start wanting more, I always just use the command
> "/bin/ksh" and then continue on...
It only matters during a system recovery where your filesystems may not be
mounted or your shared libraries are for some reason not accessible. Since
/usr/bin/ksh uses shared libs, it will not work. All executables in /sbin do
not required shared libs, so /sbin/sh is THE shell to use for root.
>
> Linux is another matter - I know enough about Linux that I routinely
> switch all root accounts to /bin/ksh. Only time it matters is if any of
> the startup scripts use a "bash-ism" and don't remember to start their
> script with "#!/bin/sh" ...
>
Since ksh (assuming you mean pdksh) follows the same convention of using shared
libraries under /lib, which should be on th "/" filesystem, that seems pretty
safe.
Out of curiousity, why do you prefer ksh over bash as a user shell? I
personally use ksh as a user shell, but use /bin/bash for root.
> FreeBSD is yet another matter - I don't know if I could switch root's
> shell without problems (their default is /bin/csh) but I don't have to.
> There is a user "toor" which is also uid 0 included in FreeBSD for
> just such a purpose - change the shell (for "toor" that is) all you
> want, that's why "toor" is there.
Kevin
| |
| David Douthitt 2004-05-19, 8:36 pm |
| Kevin Collins wrote:
> Out of curiousity, why do you prefer ksh over bash as a user shell? I
> personally use ksh as a user shell, but use /bin/bash for root.
Several reasons:
* Standard: There are no extensions to trip over when I take a Linux ksh
script into a HP-UX or Unixware environment... ksh is standard.
* Clean vi-editing support - everytime I enable vi command history
editing, I find out immediately if I'm in bash or not. Bash gives nasty
prompts and in general acts funny.
* Minimalist: pdksh (or ash, by the way) support nearly everything from
ksh and are much smaller than bash.
* Familiarization: this is personal, and somewhat professional, but I
was programming in ksh (and using csh) before bash came along. I
finally switched to ksh when I started work here as ksh was the standard
shell already and I wanted to learn it (I could have used csh).
| |
| Kevin Collins 2004-05-20, 5:37 pm |
| In article <c8gm54$o8m$1@grandcanyon.binc.net>, David Douthitt wrote:
> Kevin Collins wrote:
>
>
> Several reasons:
>
> * Standard: There are no extensions to trip over when I take a Linux ksh
> script into a HP-UX or Unixware environment... ksh is standard.
While I generally agree with that, there are differences and incompatibilities
between pure ksh88 and pdksh. The folks who post to this group who are
"portability oriented" would probably disagree more strongly.
> * Clean vi-editing support - everytime I enable vi command history
> editing, I find out immediately if I'm in bash or not. Bash gives nasty
> prompts and in general acts funny.
>
> * Minimalist: pdksh (or ash, by the way) support nearly everything from
> ksh and are much smaller than bash.
>
> * Familiarization: this is personal, and somewhat professional, but I
> was programming in ksh (and using csh) before bash came along. I
> finally switched to ksh when I started work here as ksh was the standard
> shell already and I wanted to learn it (I could have used csh).
Thanks, all valid reasons and ones I mostly share 
Kevin
| |
| Bill Vermillion 2004-08-10, 7:55 am |
| In article <c8g42b$jmv$1@grandcanyon.binc.net>,
David Douthitt <ddouthitt@cuna.coop> wrote:
>"Michael Vilain <vilain@spamcop.net>" wrote:
>
>
>I thought both HP-UX 10.20 and 11 used a POSIX sh. Trying to find the
>Bourne shell on HP-UX is always fun (sigh).
>I would have loved to switch our HP-UX systems to /bin/ksh but I didn't
>know enough about the system to do such with impunity - I've heard
>enough times the horror stories about not being able to log in and so
>forth. When I start wanting more, I always just use the command
>"/bin/ksh" and then continue on...
>Linux is another matter - I know enough about Linux that I
>routinely switch all root accounts to /bin/ksh. Only time it
>matters is if any of the startup scripts use a "bash-ism" and
>don't remember to start their script with "#!/bin/sh" ...
>FreeBSD is yet another matter - I don't know if I could switch
>root's shell without problems (their default is /bin/csh) but
>I don't have to. There is a user "toor" which is also uid 0
>included in FreeBSD for just such a purpose - change the shell
>(for "toor" that is) all you want, that's why "toor" is there.
I've been using /bin/ksh for the root shell on FreeBSD for at least
6 years now. The real ksh, not pdksh.
As to the 'toor' account it is not there to use as an alternate
shell, it's there as a safety net. The default shell for toor is
/bin/sh. The 'toor' entry doesn't even have a shell specified
so you get the default /bin/sh. It's the smallest of all shells
on FreeBSD - at 400K - but all the FreeBSD shells, and all of
/bin for that matter, is statically linked [with the exception of
rmail].
The default root shell on FreeBSD - though called csh is not
the standard csh, but is hard-linked to /bin/tcsh an ehanced
csh.
I'd advise leaving toor completely alone.
--
Bill Vermillion - bv @ wjv . com
|
|
|
|
|