root shell
Magesh Ruthrapathy
mistake in the /etc/passwd file.Now I am not able to login as root as
it says the shell doesnt exist.
Is there any way to solve this problem? Please tell me a way other
than booting the system thru CD.
The system is Ultra-2 running solaris 2.6.
Thanks for your help inadvance.
Rich Teer
> I changed the root shell to /sbin/ksh(which doesnot exist!!) by
> mistake in the /etc/passwd file.Now I am not able to login as root as
> it says the shell doesnt exist.
>
> Is there any way to solve this problem? Please tell me a way other
> than booting the system thru CD.
Basically, there isn't. You're SOL.
Don't change root's shell, as a search on google will show.
> The system is Ultra-2 running solaris 2.6.
Time to buy a Solaris 8 media kit (or download one if you
have another computer).
When you get it, change root's shell back to /sbin/sh AND LEAVE IT ALONE!
Run ksh from root's .profile.
--
Rich Teer
President,
Rite Online Inc.
Voice: +1 (250) 979-1638
URL: http://www.rite-online.net
Michael T Pins
>Don't change root's shell, as a search on google will show.
>When you get it, change root's shell back to /sbin/sh AND LEAVE IT ALONE!
Good advice.
>Run ksh from root's .profile.
Not so good advice.
If you are spending so much time as root that /sbin/sh becomes annoying,
you are already doing something wrong. root should only be used for the
things that can only be done as root.
--
**************************************************************************
* Michael T Pins | mtp...@nndev.org *
* keeper of the nn sources | mtp...@visi.com *
* ftp://ftp.nndev.org/pub | #include <std.disclaimer> *
Rich Teer
> Not so good advice.
> If you are spending so much time as root that /sbin/sh becomes annoying,
> you are already doing something wrong. root should only be used for the
> things that can only be done as root.
In priciple, I agree. But if you're a professional sysadmin, you'll
be doing stuff that can only be done as root most of the time.
For example, on a busy mail server, why type
# makemap dbm virtusertable < virtusertable
when
# r make (or perhaps better, "Esc / make")
is available to you?
I'm not suggesting for an attosecond that one should treat root
as a regular user, though. At the ISP I used to work at, I'd
log in as myself to each of their servers, then su - to root.
Then, in other windows, I'd do MY stuff, like reading mail,
surfing the web and writing documents.
Ste Kearney
> On Wed, 17 Apr 2002, Michael T Pins wrote:
>
>> Not so good advice.
>> If you are spending so much time as root that /sbin/sh becomes annoying,
>> you are already doing something wrong. root should only be used for the
>> things that can only be done as root.
>
> In priciple, I agree. But if you're a professional sysadmin, you'll
> be doing stuff that can only be done as root most of the time.
> For example, on a busy mail server, why type
>
> # makemap dbm virtusertable < virtusertable
>
> when
>
> # r make (or perhaps better, "Esc / make")
>
> is available to you?
>
> I'm not suggesting for an attosecond that one should treat root
> as a regular user, though. At the ISP I used to work at, I'd
> log in as myself to each of their servers, then su - to root.
> Then, in other windows, I'd do MY stuff, like reading mail,
> surfing the web and writing documents.
S'funny really, this Unix approach to root use. When I was living in the
wonderful world of VMS (must seek out a cheap Alpha!), I seemed to spend
most of my time logged on as SYSTEM, as far as I can remember (it was a
while ago!) there being no real su'ing concept, apart from SET ENV /CLUS
/ID=SYSTEM or something like that, to change your environment from a
regular user. Hardly anyone used that where I was though.
I think it is a console thing. Most VMS, Novell and NT server admin stuff
is done on the screen on the box or attatched terminal. whereas most
Unixheads log in remotely from their workstation for server admin, the lazy
barstewards! We used to get up and walk!
Just my humble opinions....
Ste, now wondering whether that old VAX in the garage will fire up and is
OpenVMS actaully still around......
Wayne Pollock
>
> On 17 Apr 2002, Magesh Ruthrapathy wrote:
>
> > I changed the root shell to /sbin/ksh(which doesnot exist!!) by
> > mistake in the /etc/passwd file.Now I am not able to login as root as
> > it says the shell doesnt exist.
> >
> > Is there any way to solve this problem? Please tell me a way other
> > than booting the system thru CD.
>
> Basically, there isn't. You're SOL.
Please forgive a Solaris newbie, but...
I've heard this before and I don't quite believe it. Surely there
must be an alternative to re-installing:
If you boot to single user mode won't Solaris ignore /etc/passwd
completely and run some hard-coded shell? If not, can't you login
as a regular user and run "su" (with the right arguments) to become
super-user without switching shells? If not, can't you run some
(GUI?) admin tool to fix this, that will prompt you for the root
password? If not, can't you make a boot floppy as a regular
user and boot that (to avoid booting from CDs as the OP asked)?
If not, can't you boot from a Linux floppy and mount and
fix /etc/passwd?
If all else fails, can't you properly format a floppy, then go to
any available Unix/Linux Ultra-2 box and put a copy of sh on the
floppy, make it owned by root and SUID, then pop the floppy into
the bad system, login as a regular user, mount the floppy, and
run the SUID shell?
I dimly remember on 3B20s at AT&T if all else failed there was a
diagnostic boot that ran code from ROM, as an ultimate fail-safe.
Bottom line: Have a bootable rescue floppy handy, since everyone
occasionally makes misteaks.
-Wayne
Dave Uhring
> Please forgive a Solaris newbie, but...
> I've heard this before and I don't quite believe it. Surely there
> must be an alternative to re-installing:
>
There is; have a Software CD 1 available.
> If you boot to single user mode won't Solaris ignore /etc/passwd
> completely and run some hard-coded shell?
You can do that with Linux and FreeBSD; you cannot do it with Solaris.
> If not, can't you login
> as a regular user and run "su" (with the right arguments) to become
> super-user without switching shells?
No, root has no shell.
> If not, can't you run some
> (GUI?) admin tool to fix this, that will prompt you for the root
> password?
Who is going to run the GUI tool? Root cannot login.
> If not, can't you make a boot floppy as a regular
> user and boot that (to avoid booting from CDs as the OP asked)?
> If not, can't you boot from a Linux floppy and mount and
> fix /etc/passwd?
>
If your Linux floppy can properly mount a Solaris UFS partition, it
might be possible. Better to use a Solaris CD.
> If all else fails, can't you properly format a floppy, then go to
> any available Unix/Linux Ultra-2 box and put a copy of sh on the
> floppy, make it owned by root and SUID, then pop the floppy into
> the bad system, login as a regular user, mount the floppy, and
> run the SUID shell?
>
The Solaris kernel is too big to fit on a floppy.
> I dimly remember on 3B20s at AT&T if all else failed there was a
> diagnostic boot that ran code from ROM, as an ultimate fail-safe.
>
> Bottom line: Have a bootable rescue floppy handy, since everyone
> occasionally makes misteaks.
See above regarding the size of the kernel.
Drazen Kacar
> Wayne Pollock wrote:
>
> > Please forgive a Solaris newbie, but...
> > I've heard this before and I don't quite believe it. Surely there
> > must be an alternative to re-installing:
>
> There is; have a Software CD 1 available.
There's always Stop-A and putting zero at the strategical place in the
shell cred structure from PROM. If on SPARC and if one regular user can
log in.
> > If all else fails, can't you properly format a floppy, then go to
> > any available Unix/Linux Ultra-2 box and put a copy of sh on the
> > floppy, make it owned by root and SUID, then pop the floppy into
> > the bad system, login as a regular user, mount the floppy, and
> > run the SUID shell?
>
> The Solaris kernel is too big to fit on a floppy.
Just the shell.
--
.-. .-. I don't work here. I'm a consultant.
(_ \ / _)
| da...@willfork.com
|
Dave Uhring
> Just the shell.
>
You are correct. That might work, but would have to be done before
hosing root's shell in /etc/passwd, or perhaps doing it on another
machine on which root's shell still works.
bit-b...@maney.org
: Rich Teer wrote:
:>
:> On 17 Apr 2002, Magesh Ruthrapathy wrote:
:>
:> > I changed the root shell to /sbin/ksh(which doesnot exist!!) by
:> > mistake in the /etc/passwd file.Now I am not able to login as root as
:> > it says the shell doesnt exist.
:> >
:> > Is there any way to solve this problem? Please tell me a way other
:> > than booting the system thru CD.
:>
:> Basically, there isn't. You're SOL.
:> ...
: Please forgive a Solaris newbie, but...
: I've heard this before and I don't quite believe it.
Believe it. Short of exploiting a really grievous security hole (like
using ftp, rcp or scp as root to dump a new /etc/passwd file into place,
you are SOL and need to boot from CD.
: Surely there must be an alternative to re-installing:
Who said anything about reinstalling?
: If you boot to single user mode won't Solaris ignore /etc/passwd
: completely and run some hard-coded shell?
Nope.
: If not, can't you login as a regular user and run "su" (with the
: right arguments) to become super-user without switching shells?
Nope.
: If not, can't you run some (GUI?) admin tool to fix this, that will
: prompt you for the root password?
Nope. They require that you are already root before you run them (it's
a security thing).
: If not, can't you make a boot floppy as a regular user and boot
: that (to avoid booting from CDs as the OP asked)?
There is no such thing as a Solaris boot floppy.
: If not, can't you boot from a Linux floppy and mount and
: fix /etc/passwd?
The OP was (presumably) wanting to not boot from CD because he didn't
want the downtime, not because he didn't want to use the CD.
: If all else fails, can't you properly format a floppy, then go to
: any available Unix/Linux Ultra-2 box and put a copy of sh on the
: floppy, make it owned by root and SUID, then pop the floppy into
: the bad system, login as a regular user, mount the floppy, and
: run the SUID shell?
*Maybe*. Though I'm fairly certain you must be root to mount the
floppy with the proper permissions.
: I dimly remember on 3B20s at AT&T if all else failed there was a
: diagnostic boot that ran code from ROM, as an ultimate fail-safe.
: Bottom line: Have a bootable rescue floppy handy, since everyone
: occasionally makes misteaks.
That's why you keep the install media and/or jumpstart available.
fpsm
--
| Fredrich P. Maney my_last_name AT my_last_name DOT org |
| Do NOT send me HTML formatted E-mail or copies of netnews posts! |
| Address in header is a spamtrap. Use one in signature for replies. |
| Please review http://www.maney.org/fred/site/uce/ before emailing. |
Martin Paul
> On Wed, 17 Apr 2002 22:33:31 -0400 in comp.unix.solaris Wayne Pollock wrote:
> : If all else fails, can't you properly format a floppy, then go to
> : any available Unix/Linux Ultra-2 box and put a copy of sh on the
> : floppy, make it owned by root and SUID, then pop the floppy into
> : the bad system, login as a regular user, mount the floppy, and
> : run the SUID shell?
>
> *Maybe*. Though I'm fairly certain you must be root to mount the
> floppy with the proper permissions.
Yep. You have to be root to mount filesytems manually with the mount
command. Users can mount floppies using the volume manager, which uses
rmmount to do the mount, and in rmmount's man page you find:
File systems mounted by rmmount are always mounted with the
nosuid flag set, thereby disabling set-uid programs and
access to block or character devices in that file system.
mp.
--
Martin Paul | Systems Administrator
Institute for Software Science | mar...@par.univie.ac.at
Liechtensteinstrasse 22, A-1090 Wien | Tel: 01 4277 38803
http://www.par.univie.ac.at/ | Fax: 01 4277 9388
Chris Morgan
> I think it is a console thing. Most VMS, Novell and NT server admin stuff
> is done on the screen on the box or attatched terminal. whereas most
> Unixheads log in remotely from their workstation for server admin, the lazy
> barstewards! We used to get up and walk!
When I log into my machines to do some admin, I am somwhere between 2
feet and 3 thousand miles away. since ssh works reasonably well in all
cases, it's a better habit than using the graphics console
>
> Just my humble opinions....
>
> Ste, now wondering whether that old VAX in the garage will fire up and is
> OpenVMS actaully still around......
Yes, but what would you actually do with it? Lots of coolness points,
but those things need substantial power and maybe cooling!
Chris
--
Chris Morgan <cm at mihalis.net> http://www.mihalis.net
Temp sig. - Enquire within
Noel R. Nihill
<bit-b...@maney.org> wrote in message
news:a9mdkr$6js$1...@newsread.stdio.com...
> On Wed, 17 Apr 2002 22:33:31 -0400 in comp.unix.solaris Wayne Pollock
wrote:
> : Rich Teer wrote:
> :>
> :> On 17 Apr 2002, Magesh Ruthrapathy wrote:
> :>
> :> > I changed the root shell to /sbin/ksh(which doesnot exist!!) by
> :> > mistake in the /etc/passwd file.Now I am not able to login as root as
> :> > it says the shell doesnt exist.
> :> >
> :> > Is there any way to solve this problem? Please tell me a way other
> :> > than booting the system thru CD.
> :>
> :> Basically, there isn't. You're SOL.
> :> ...
>
> : Please forgive a Solaris newbie, but...
> : I've heard this before and I don't quite believe it.
>
> Believe it. Short of exploiting a really grievous security hole (like
> using ftp, rcp or scp as root to dump a new /etc/passwd file into place,
> you are SOL and need to boot from CD.
Well, I'll just add:
This is from dev...@my-deja.com, September 17th 2000
on this newsgroup. I would add that Solaris 8 will show the
shell process's address if you go 'ps -o addr':
<devkmem>
Unless you've lost the PROM password as well (ach!), here's a faster
way to regain root privileges on a Sun machine.
At least till Solaris 2.5, "/usr/bin/ps -l" showed you the address
of the proc{} structure (under the ADDR field). Sun figured (I guess)
that this was a security hole, because for somebody with console
access, one could simply hit Stop-A, and on machines with no PROM
passwords, this meant you could figure out the offset of the cr_uid
field in the credential structure in the proc{} structure, etc, etc
and write a 0 there. If you did it to your login shell, you gained
root.
[NRN:] The OpenBoot instruction to use for this sort of thuggery
is 'mkp'. Its syntax is <value> <address> mkp [return]. [/NRN]
With Solaris 7 and 8 (not sure about 2.6), the ADDR field displays
a mere '?'. However, you can boot your system into the kernel
debugger (at the "ok" prompt, type "boot kadb"). Then login as
anybody (this assumes you have at least one login left on the machine).
Then note the pid of your shell, and convert it to hex (for simplicity).
Then, hit Stop-A - you go into the debugger. Suppose the pid is
0xbaddcafe (!), then:
20::more
0xbaddcafe$<pid2proc
/* note the address of the credential structure.
* assume this is 0xfeedface.
*/
0xfeedface,f/Xa
/* note the fields containing your uid's. refer
* to <sys/cred.h> for offsets.
*/
0xfeedface+<offset>?W 0 /* write a zero to a uid field */
:c /* continue */
You are root now.
</devkmem>
[snipped]
> fpsm
> --
> | Fredrich P. Maney my_last_name AT my_last_name DOT org |
> | Do NOT send me HTML formatted E-mail or copies of netnews posts! |
> | Address in header is a spamtrap. Use one in signature for replies. |
> | Please review http://www.maney.org/fred/site/uce/ before emailing. |
__________________________
Noel R. Nihill
UNIXŽ platform development
Motorola NSS.
__________________________
'as_setprot' heuristic gave my process a wedgie.
Wayne Pollock
>
> <bit-b...@maney.org> wrote in message
> news:a9mdkr$6js$1...@newsread.stdio.com...
> > On Wed, 17 Apr 2002 22:33:31 -0400 in comp.unix.solaris Wayne Pollock
> wrote:
> > : Rich Teer wrote:
> > :>
> > :> On 17 Apr 2002, Magesh Ruthrapathy wrote:
> > :>
> > :> > I changed the root shell to /sbin/ksh(which doesnot exist!!) by
> > :> > mistake in the /etc/passwd file.Now I am not able to login as root as
> > :> > it says the shell doesnt exist.
> > :> >
> > :> > Is there any way to solve this problem? Please tell me a way other
> > :> > than booting the system thru CD.
> > :>
> > :> Basically, there isn't. You're SOL.
> > :> ...
> >
> > : Please forgive a Solaris newbie, but...
> > : I've heard this before and I don't quite believe it.
> >
> > Believe it. Short of exploiting a really grievous security hole (like
> > using ftp, rcp or scp as root to dump a new /etc/passwd file into place,
> > you are SOL and need to boot from CD.
>
> Well, I'll just add:
>
> This is from dev...@my-deja.com, September 17th 2000
> on this newsgroup. I would add that Solaris 8 will show the
> shell process's address if you go 'ps -o addr':
> You are root now.
See? I knew there was a *simple* way! :-)
(I assumed the OP didn't want to use CDs because they were no longer
available.)
Also, what about NFS, would that allow one to login to BAD machine
as regular user and run some SUID shell from some other GOOD
machine (that you have root access to)? Naturally this assumes
BAD has already mounted some GOOD directory.
-Wayne
PS What would be a recommened book (no on-line resources please)
for someone with a strong Unix and Linux background to learn
Solaris 8 or 9 system administration? I'm looking to learn
Solaris specific stuff: booting, Solaris role-based security,
Solaris ACLs (?), Solaris GUI, Solaris updating, configuration
and tuning. I'm not looking for a tutorial for new SAs, a
good reference with some overview would be enough. Any ideas?
Betsy Schwartz
wrote:
>Also, what about NFS, would that allow one to login to BAD machine
>as regular user and run some SUID shell from some other GOOD
>machine (that you have root access to)? Naturally this assumes
>BAD has already mounted some GOOD directory.
Er, that would only be possible if a) the root directory is exported
and mounted and b) it is mounted to allow suid root from remote
systems. This would be a massively gaping security hole, plus there's
no reason for one machine's root to have been mounted on another
machine because every machine has their own root (diskless
workstations usually mount root from an export directory (um, was it
/export/root? It's been a while) not the server's root.
So, I doub't you'd ever find a system set up this way.
>-Wayne
>
>PS What would be a recommened book (no on-line resources please)
> for someone with a strong Unix and Linux background to learn
> Solaris 8 or 9 system administration?
I always like "Unix System Administration Handbook" by Nemeth,
Seebass, Snyder et all for multicultural stuff. I've flipped through
the Osborne book "Solaris 8: The Complete Reference" bt Watter sand
Verraraghavan and it seems like a nice overview, but not complete.
The docs on docs.sun.com are required reading - you can print them out
if you don't like online references - there is a 3-volume Solaris 8
admin set that you absolutely will want to print out and keep around.
Noel R. Nihill
"Wayne Pollock" <pol...@acm.org> wrote in message
news:3CBEDD65...@acm.org...
Where there's a wally, there's a way...
> (I assumed the OP didn't want to use CDs because they were no longer
> available.)
>
> Also, what about NFS, would that allow one to login to BAD machine
> as regular user and run some SUID shell from some other GOOD
> machine (that you have root access to)? Naturally this assumes
> BAD has already mounted some GOOD directory.
Most certainly not! root on an NFS client is an entirely different
animal from root on any corresponding NFS server.
> -Wayne
>
> PS What would be a recommened book (no on-line resources please)
Tough. You're getting some ;-)
> for someone with a strong Unix and Linux background to learn
> Solaris 8 or 9 system administration? I'm looking to learn
> Solaris specific stuff: booting, Solaris role-based security,
> Solaris ACLs (?), Solaris GUI, Solaris updating, configuration
> and tuning. I'm not looking for a tutorial for new SAs, a
> good reference with some overview would be enough. Any ideas?
Start here, with Casper Dik's Solaris 2 FAQ:
http://www.science.uva.nl/pub/solaris/solaris2/
...and look at question 2.7 for reccomendations on further reading.
__________________________
Noel R. Nihill
UNIX® platform development
Michael Schrader-Boelsche
> Rich Teer wrote:
>
> If all else fails, can't you properly format a floppy, then go to
> any available Unix/Linux Ultra-2 box and put a copy of sh on the
> floppy, make it owned by root and SUID, then pop the floppy into
> the bad system, login as a regular user, mount the floppy, and
> run the SUID shell?
In the default configuration the Solaris volume manager will mount
a filesystem on a removable media with the option nosuid set.
I'm sorry, it will not work.
Just boot from the second installation CD "Software 1/2" or
swap the disk to working sun where you have root access, mount the
filesystem and edit /etc/passwd.
Michael
--
Michael Schrader-Bölsche m...@tanum-consult.de
Tanum Consult GmbH Fax +49 (0)40 88169010
Hamburg, Germany http://www.tanum-consult.de
Michael T Pins
>On Wed, 17 Apr 2002, Michael T Pins wrote:
>> Not so good advice.
>> If you are spending so much time as root that /sbin/sh becomes annoying,
>> you are already doing something wrong. root should only be used for the
>> things that can only be done as root.
>In priciple, I agree. But if you're a professional sysadmin, you'll
>be doing stuff that can only be done as root most of the time.
Considering I'm root on a continent-wide network, I'd say I qualify as a
"professional sysadmin". Oddly, most of the time I'm doing things that
don't require root privs.
>For example, on a busy mail server, why type
> # makemap dbm virtusertable < virtusertable
>when
> # r make (or perhaps better, "Esc / make")
>is available to you?
If you're changing the map that often, write a script.
Michael T Pins
>I think it is a console thing. Most VMS, Novell and NT server admin stuff
>is done on the screen on the box or attatched terminal. whereas most
>Unixheads log in remotely from their workstation for server admin, the lazy
>barstewards! We used to get up and walk!
Considering I live in Colorado, and I spend most of my time working on
machines in California and Quebec, walking to the consoles would be a bit
difficult....
Michael T Pins
>Rich Teer wrote:
>>
>> On 17 Apr 2002, Magesh Ruthrapathy wrote:
>>
>> > I changed the root shell to /sbin/ksh(which doesnot exist!!) by
>> > mistake in the /etc/passwd file.Now I am not able to login as root as
>> > it says the shell doesnt exist.
>> >
>> > Is there any way to solve this problem? Please tell me a way other
>> > than booting the system thru CD.
>>
>> Basically, there isn't. You're SOL.
>> ...
>Please forgive a Solaris newbie, but...
>I've heard this before and I don't quite believe it. Surely there
>must be an alternative to re-installing:
Certainly. Boot from CD. Break out to a shell. Mount /etc from the disk.
Edit /etc/passwd. Reboot.
This isn't windoze.
>If you boot to single user mode won't Solaris ignore /etc/passwd
>completely and run some hard-coded shell?
No. Single-user still reads the shell out of /etc/passwd.
>Bottom line: Have a bootable rescue floppy handy, since everyone
>occasionally makes misteaks.
No such thing as a bootable floppy for Solaris. No need, boot the install
CD. And no, everyone doesn't make that kind of idiotic mistake.
Wayne Pollock
> > PS What would be a recommened book (no on-line resources please)
>
> Tough. You're getting some ;-)
>
> > for someone with a strong Unix and Linux background to learn
> > Solaris 8 or 9 system administration? I'm looking to learn
> > Solaris specific stuff: booting, Solaris role-based security,
> > Solaris ACLs (?), Solaris GUI, Solaris updating, configuration
> > and tuning. I'm not looking for a tutorial for new SAs, a
> > good reference with some overview would be enough. Any ideas?
>
> Start here, with Casper Dik's Solaris 2 FAQ:
>
> http://www.science.uva.nl/pub/solaris/solaris2/
>
> ...and look at question 2.7 for reccomendations on further reading.
I've been through that FAQ. (Couldn't find a more recent one,
for Solaris 8.) It doesn't actually name any Solaris specific
books at all! Judging from the available FAQs, recommendations
here, and a search on Amazon.com, I'd have to say there don't seem
to be *any* Solaris 8 books worth the money. (The 3 volume
set from Sun is pricey in hardcopy but apparently free on-line.)
So if any of you experts wants to write one, the world is
waiting...
Thanks for the help!
-Wayne
Wayne Pollock
Thanks for the feed-back. I have seen the on-line version of that
3-volume set, but wasn't sure if it would worth the big bucks to
buy in hardcopy.
-Wayne Pollock
Rich Teer
> So if any of you experts wants to write one, the world is
> waiting...
Sorry, I'm already tied up writing "Solaris Systems Programming".
--
Rich Teer - with tongue firmly in cheek! :-)
Ste Kearney
Hey, Chris!
It's only a VaxStation 3100.
A 286 really!!
Ste
Anthony Mandic
> PS What would be a recommened book (no on-line resources please)
> for someone with a strong Unix and Linux background to learn
> Solaris 8 or 9 system administration? I'm looking to learn
> Solaris specific stuff: booting, Solaris role-based security,
> Solaris ACLs (?), Solaris GUI, Solaris updating, configuration
> and tuning. I'm not looking for a tutorial for new SAs, a
> good reference with some overview would be enough. Any ideas?
The Sobel book is often recommended. But the best advice would
be to go to a bookstore and look at some of the ones available
and decide for yourself.
-am © 2002
bit-b...@maney.org
[...]
: I've been through that FAQ. (Couldn't find a more recent one,
: for Solaris 8.) It doesn't actually name any Solaris specific
: books at all! Judging from the available FAQs, recommendations
: here, and a search on Amazon.com, I'd have to say there don't seem
: to be *any* Solaris 8 books worth the money. (The 3 volume
: set from Sun is pricey in hardcopy but apparently free on-line.)
If you are just wanting a decent overview of the OS for someone who
is already familiar with other flavors of Unix, I'd suggest picking
up one of the Solaris Study Guides from Exam Cram.
: So if any of you experts wants to write one, the world is
: waiting...
I'll dig through my bookshelf at the apartment this weekend (I won't
be back at the house for at least a week, probably two) and see what
I can come up with as far as a list goes.
In general though, I'd say your best resources are going to be:
http://docs.sun.com/
http://soldc.sun.com/
http://www.science.uva.nl/pub/solaris/solaris2.html
http://www.solariscentral.org/
http://www.solarisguide.com/
http://www.everythingsolaris.org/
Chris Morgan
> >> Ste, now wondering whether that old VAX in the garage will fire up and is
> >> OpenVMS actaully still around......
> >
> > Yes, but what would you actually do with it? Lots of coolness points,
> > but those things need substantial power and maybe cooling!
> >
> > Chris
> Hey, Chris!
>
> It's only a VaxStation 3100.
>
> A 286 really!!
Well that's ok then. About the only thing I ever wanted to have at
home that a vaxstation would give me was access to DECAda, but that
was a long long time ago, in a galaxy far far way, and besides, the
wench is dead.
Chris
-badly mangled quotes'r'us
--
Chris Morgan
"Not so bad offer to discuss about"
- Best recent email spam subject line
Daniel Price
> Rich Teer wrote:
>>
>> On 17 Apr 2002, Magesh Ruthrapathy wrote:
>>
>> > I changed the root shell to /sbin/ksh(which doesnot exist!!) by
>> > mistake in the /etc/passwd file.Now I am not able to login as root as
>> > it says the shell doesnt exist.
>> >
>> > Is there any way to solve this problem? Please tell me a way other
>> > than booting the system thru CD.
>>
>> Basically, there isn't. You're SOL.
>> ...
>
> Please forgive a Solaris newbie, but...
> I've heard this before and I don't quite believe it. Surely there
> must be an alternative to re-installing:
>
> If you boot to single user mode won't Solaris ignore /etc/passwd
> completely and run some hard-coded shell? If not, can't you login
> as a regular user and run "su" (with the right arguments) to become
> super-user without switching shells?
We (some folks in the kernel group) had the same conversation over lunch
a few months ago; in particular, we were tired of hearing this tale of woe
on comp.unix.solaris. As a result, this is fixed in Solaris 9.
Here is the new policy:
- If su(1M) (and only su, not login(1)) discovers that it couldn't
exec(2) the root user's shell even though the correct password
was supplied, it assumes that the root user screwed up the shell;
it then goes to "fallback mode" and exec's /sbin/sh.
- This policy is only in effect for su to the root account,
since some sites may use a bogus shell to lock out users
(such as /bin/not_a_shell).
- The best news here is that the single-user-mode login prompt
is really su in disguise. So if you've completely locked yourself
out, simply reboot the system to single user mode, and at the
single-user-mode login prompt, give the root password; when
exec of the root shell fails, it will fall back to /sbin/sh.
- Simply hard-coding /sbin/sh as the single user mode shell as
Wayne suggests above was considered, but that seemed to violate
the "principle of least surprise." We could investigate that
in the future if problems persist.
Here is an example of the new behavior; in this case I've set root's
shell to /sbin/ksh:
$ id
uid=99999(dp) gid=10(staff)
$ su root
Password: <give correct passwd>
su: No shell /sbin/ksh. Trying fallback shell /sbin/sh.
#
I know that c.u.s. has seen extensive debate on the topic of altering
root's shell, so please note that while this fix will hopefully help
the people who make this mistake, it does *not* completely alleviate
problems which folks have noted when using shells other than /sbin/sh
as the root shell. In particular it does not address problems which
may occur at single-user-mode with dynamically linked shells.
I recommend adding a separate 'rook' account which has uid=0 and uses
/usr/bin/ksh.
For those who care, the subtle problem with using dynamically linked
shells is that runtime link problems can occur at single user mode if
the shell depends on libraries in /usr. This will happen if /usr is
on a separate partition from /, and is damaged or not yet mounted.
Again, the aforementioned fix will be available beginning with Solaris 9
FCS.
-dp
--
Daniel Price - Solaris Kernel Development - d...@eng.sun.com
Expressed in this posting are my opinions. They are in no way related to
opinions held by my employer, Sun Microsystems. Statements on Sun products
included here are not gospel and may be fiction rather than truth.
Dave Uhring
> I recommend adding a separate 'rook' account which has uid=0 and uses
> /usr/bin/ksh.
Why don't you like the 'toor' account name?
Anthony Mandic
> We (some folks in the kernel group) had the same conversation over lunch
> a few months ago; in particular, we were tired of hearing this tale of woe
> on comp.unix.solaris.
I think we're all tired of hearing it.
> As a result, this is fixed in Solaris 9.
>
> Here is the new policy:
>
> - If su(1M) (and only su, not login(1)) discovers that it couldn't
> exec(2) the root user's shell even though the correct password
> was supplied, it assumes that the root user screwed up the shell;
> it then goes to "fallback mode" and exec's /sbin/sh.
...
> - Simply hard-coding /sbin/sh as the single user mode shell as
> Wayne suggests above was considered, but that seemed to violate
> the "principle of least surprise." We could investigate that
> in the future if problems persist.
I would like to see comments supported in the /etc/passwd file.
The Sun supplied default file could contain one comment after
the root entry informing users not to be stupid.
-am © 2002
Kjetil Torgrim Homme
> I would like to see comments supported in the /etc/passwd file.
> The Sun supplied default file could contain one comment after
> the root entry informing users not to be stupid.
you may be saying this in jest, but it would be a bad idea to support
comments in /etc/passwd due to compatibility with other Unixen.
--
Kjetil T. [ http://www.petitiononline.com/warcrime/petition.html ]
Chris Thompson
Obviously it's meant to be mnemonic: "rook" for the root account that uses
ksh, "roob" for the one that uses bash, "rooz" for the one that uses zsh,
"root" for the one that uses tcsh ...
Chris Thompson
Email: cet1 [at] cam.ac.uk
Dave Uhring
"toor" is the name used in BSD for the second account with UID=0 and is
IMHO something which should never have been dreamed up, just like
"rook".
Adding accounts with UID=0 for the reasons stated is just plain silly.
Rich Teer
"Rook" is obviously short for "Rookie". :-)
--
Rich Teer
Rich Teer
> I would like to see comments supported in the /etc/passwd file.
> The Sun supplied default file could contain one comment after
> the root entry informing users not to be stupid.
I honestly think that wouldn't help much. Some people just
insist on being stupid, no matter how much you try to tell 'em.
Just a few months ago in this newsgroup, there was a guy who
said words to the effect of "I've heard that changing root's
shell is really stupid and shouldn't be done, but I did it
anyway. Now I can't log in as root - please help."
Then there's all the millions of fools using Windoze for
their business critival operations (admittedly, some of
those DON'T know how dumb they're being), despite all the
virus and other security warning, and despite M$ being a
convicted monopolist.
If those two examples don't illustrate my point, nothing
will...
bit-b...@maney.org
[...]
: I would like to see comments supported in the /etc/passwd file.
: The Sun supplied default file could contain one comment after
: the root entry informing users not to be stupid.
Not a good idea and I doubt that it would do much good anyway.
I'd rather see more of a push to use /usr/ucb/vipw to edit /etc/passwd,
as well as error checking routines in /bin/pwconv.
If we are constructing a wish list though, I've got a few to add .....
- I'd also like to see much more of a security conscious mindset in
the default configurations (disallowing remote root logins, greater
password construction controls, fewer services on by default, less
reliance on things such as java, etc..).
- I'd like to see Sun implement something like the LED/LCD panel on
the front of IBM RS6000 machines for error notification and monitoring
of the POST.
- I'd like to see some actual development done on admintool. If it
were even half as good as SMIT/smitty from AIX (including a CLI as
well as the GUI), it would make Solaris *much* more attractive to
the end-user, while alos allowing for a lot of "protecting the
idiots" code to be added in the background.
- I'd like to see some sort of automatic, standard hot disaster recovery
method. It would be nice to have something better than "re-install
and restore". Something like mksysb (bootable tape that will recreate
the rootvg as it was before the crash, create and layout the filesystems
and volume groups and make everything ready for the data restore)
from AIX would be wonderful.
Anthony Mandic
> > I would like to see comments supported in the /etc/passwd file.
> > The Sun supplied default file could contain one comment after
> > the root entry informing users not to be stupid.
>
> you may be saying this in jest, but it would be a bad idea to support
> comments in /etc/passwd due to compatibility with other Unixen.
Compatibility for what? I don't see the need for any here.
-am © 2002
Anthony Mandic
> I honestly think that wouldn't help much. Some people just
> insist on being stupid, no matter how much you try to tell 'em.
>
> Just a few months ago in this newsgroup, there was a guy who
> said words to the effect of "I've heard that changing root's
> shell is really stupid and shouldn't be done, but I did it
> anyway. Now I can't log in as root - please help."
I know but if they shoot themselves in the foot at least
they can't claim that they weren't warned.
-am © 2002
Anthony Mandic
> Not a good idea and I doubt that it would do much good anyway.
It would act as more of a "you have no one to blame but yourself"
type of warning.
> I'd rather see more of a push to use /usr/ucb/vipw to edit /etc/passwd,
> as well as error checking routines in /bin/pwconv.
The trick is to prevent other editors being able to edit it.
Vi can be changed but Sun don't have any control over third
party editors. The only other solution is to change /etc/passwd
into something other than a text file. I don't particularly
like the idea of that.
> If we are constructing a wish list though, I've got a few to add .....
>
> - I'd also like to see much more of a security conscious mindset in
> the default configurations (disallowing remote root logins, greater
> password construction controls, fewer services on by default, less
> reliance on things such as java, etc..).
The first one is off by default. Fewer services, yes.
> - I'd like to see Sun implement something like the LED/LCD panel on
> the front of IBM RS6000 machines for error notification and monitoring
> of the POST.
The V880 does have a diagnotic front panel but its hardware
only. And even then its only some simple stuff but its a
step in the right direction.
> - I'd like to see some actual development done on admintool. If it
> were even half as good as SMIT/smitty from AIX (including a CLI as
> well as the GUI), it would make Solaris *much* more attractive to
> the end-user, while alos allowing for a lot of "protecting the
> idiots" code to be added in the background.
I agree with this.
> - I'd like to see some sort of automatic, standard hot disaster recovery
> method. It would be nice to have something better than "re-install
> and restore". Something like mksysb (bootable tape that will recreate
> the rootvg as it was before the crash, create and layout the filesystems
> and volume groups and make everything ready for the data restore)
> from AIX would be wonderful.
This, of course, assumes that backups have been made. And we all
know the quality of that assumption.
-am © 2002
Rich Teer
> I know but if they shoot themselves in the foot at least
> they can't claim that they weren't warned.
How about a comromise? Change root's GCOS field from
"Super-User" to "Don't change root's shell, knucklehead".
You get a comment AND backwards compatibility!
Hans Jørgensen
> # > I know but if they shoot themselves in the foot at least
> # > they can't claim that they weren't warned.
> # How about a comromise? Change root's GCOS field from
> # "Super-User" to "Don't change root's shell, knucklehead".
> # You get a comment AND backwards compatibility!
> Genius!
I think all this "don't change roots shell"-stuff is a bit
silly ..
I have been working with Solaris for about 2 years now, run
lots of server, and most with bash as roots shell...
And everything works great... i can't really see the
problem..
--
Hans Joergensen, http://www.nathue.dk
Dave Uhring
> I think all this "don't change roots shell"-stuff is a bit
> silly ..
> I have been working with Solaris for about 2 years now, run
> lots of server, and most with bash as roots shell...
>
> And everything works great... i can't really see the
> problem..
>
If you recognize that bash is in /usr/bin and not in /bin, and if you
create /etc/shells with the appropriate shells, you are probably safe
in doing this. Unless you have separated the / and /usr partitions and
your /usr partition gets clobbered and cannot be mounted or has some
critical libraries corrupted.
/sbin/sh is on the / partition and is linked statically.
Noel R. Nihill
"Hans Jørgensen" <h...@mostlyharmless.telianisse.org> wrote in message
news:slrnacbel...@pesthest.nathue.dk...
Oh no...
Rich, kill!!
> --
> Hans Joergensen, http://www.nathue.dk
__________________________
Noel R. Nihill
UNIX® platform development
Motorola NSS.
__________________________
'as_setprot' heuristic gave my process a wedgie.
Hans Jørgensen
> If you recognize that bash is in /usr/bin and not in /bin, and if you
> create /etc/shells with the appropriate shells, you are probably safe
> in doing this. Unless you have separated the / and /usr partitions and
> your /usr partition gets clobbered and cannot be mounted or has some
> critical libraries corrupted.
> /sbin/sh is on the / partition and is linked statically.
Well, you always have the option to boot on a cd or via
network..
Dave Uhring
If you insist on using bash as a root shell, you are much safer by
creating /.profile with contents [ -x /usr/bin/bash && /usr/bin/bash ]
And leaving /sbin/sh as the true root shell.
Rich Teer
> I have been working with Solaris for about 2 years now, run
> lots of server, and most with bash as roots shell...
Two whole years, eh? Plenty of time to fsck thing up then.
I'm betting your background is Linux...
Rich Teer
> Oh no...
>
> Rich, kill!!
Battle computers online...
Acquiring target...
Photon torpedoes with protoplasmic laceterors launched!
Rich Teer
> Well, you always have the option to boot on a cd or via
> network..
Not if your single Solaris box is 200 miles away in a co-lo
facility (or even accross town), or you can't find your
media (it happens), ot its your boot server that's FUBARed.
What the next "I'll carry on using my bad habits despite
good advice from those more experienced than me" excuse? ;-)
Hint: what is OK for a home box to play with isn't necessarily
kosher in a mission critical data centre environment. Downtime
can cost a LOT of money, so reducing it is a Good Thing. And
that means using a statically linked root shell on the /
partition.
Kjetil Torgrim Homme
okay, I think it is bad bad bad that killall on Linux behaves
differently than on SVR4. it doesn't impact the usability of the
system, but it can give a sysadmin and his users a nasty surprise.
I've seen someone put in a comment in /etc/passwd. this generally
"works" to comment out an entry (the username is funny), but on this
system[1], processing would be abandoned when a line with the wrong
number of colons was encountered. as a result, most users were locked
out...
[1] sorry, can't remember what OS.
(it's also a feature that the format of /etc/passwd matches the format
in NIS -- comments don't fit in very well there.)
--
Kjetil T. [ nerd #5 -- http://nerdquiz.thathost.com ]
Anthony Mandic
> How about a comromise? Change root's GCOS field from
> "Super-User" to "Don't change root's shell, knucklehead".
> You get a comment AND backwards compatibility!
Yes, that does a certain appeal. I'd try for something
to match "GCOS" but I can't get further than "Get a Clue".
-am © 2002
Anthony Mandic
> (it's also a feature that the format of /etc/passwd matches the format
> in NIS -- comments don't fit in very well there.)
Well, I didn't say it would be easy. An extra comment field could
be added at the end but it would also have implications. The GCOS
approach would probably be the best.
-am © 2002
Rich Teer
How about "Get a Clue Or Screw up"? ;-)
Hans Jørgensen
> On 23 Apr 2002, Hans J=F8rgensen wrote:
>> Well, you always have the option to boot on a cd or via
>> network..
> Not if your single Solaris box is 200 miles away in a co-lo
> facility (or even accross town), or you can't find your
> media (it happens), ot its your boot server that's FUBARed.
You are right about that one...
But, does it really matter if you have a shell thats linked
aginst libraries in /usr .. ? you can't get the system
running with a broken /usr anyway ...
(which fsck)
> What the next "I'll carry on using my bad habits despite
> good advice from those more experienced than me" excuse? ;-)
I think i'll just continue my habits untill they turn
out bad, and they have not done that yet.. (only my
Cola-habit has;o) ..
> Hint: what is OK for a home box to play with isn't necessarily
> kosher in a mission critical data centre environment. Downtime
> can cost a LOT of money, so reducing it is a Good Thing. And
> that means using a statically linked root shell on the /
> partition.
Well, we normally run mission critical services on more than
one server and balance it with dns-roundrobin, that way we
can take over a broken servers ip (or just redirect it in
the switch) if a server breaks.
This works fine, uptimes on 99.9x% on all services should
proff that...
Hans Jørgensen
>> I have been working with Solaris for about 2 years now, run
>> lots of server, and most with bash as roots shell...
> Two whole years, eh? Plenty of time to fsck thing up then.
> I'm betting your background is Linux...
Your right .. but, Linux is not that bad a background ..
And, i have see quite a few techies from SUN that has less
of a clue than i have ..
Hans Jørgensen
> okay, I think it is bad bad bad that killall on Linux behaves
> differently than on SVR4. it doesn't impact the usability of the
> system, but it can give a sysadmin and his users a nasty surprise.
I think that it's pretty dumb that killall acts the way it
does on SVR4 .. a command that kill's all is meaningless...
Rich Teer
> But, does it really matter if you have a shell thats linked
> aginst libraries in /usr .. ? you can't get the system
If you worked for me it would: you'd be fired.
> running with a broken /usr anyway ...
> (which fsck)
fsck assumes that you want to check the whole file system.
What if someone renames one of the dynamic libraries that
bash relises on, remotely.
> I think i'll just continue my habits untill they turn
> out bad, and they have not done that yet.. (only my
> Cola-habit has;o) ..
Sigh. OK, I tried: it's your career...
> This works fine, uptimes on 99.9x% on all services should
> proff that...
Only 99.9%? That's a whole day of downtime per year. ;-)
Hey - do what you want, but taking some advice from those
more experienced is the way to true happiness...
Rich Teer
> Your right .. but, Linux is not that bad a background ..
From what I've seen, it is! For a start, you think that
using a dynamically linked shell is not a bad idea! I bet
you install gcc on all of your machines too...
> And, i have see quite a few techies from SUN that has less
> of a clue than i have ..
Depends on what they do. You can't be an expert in everything.
Hans Jørgensen
>> But, does it really matter if you have a shell thats linked
>> aginst libraries in /usr .. ? you can't get the system
> If you worked for me it would: you'd be fired.
Glad i don't then..
>> running with a broken /usr anyway ...
>> (which fsck)
> fsck assumes that you want to check the whole file system.
Eeh... and that helps you in what way if the /usr-filesystem
is broken and you can't get to /usr/sbin/fsck ?
> What if someone renames one of the dynamic libraries that
> bash relises on, remotely.
What if someone renames /sbin/sh ?
What if someone renames /kernel ?
What if someone without brain runs format?
I can't think of why anyone should rename a library bash
relies on.
haj@pesthest ~ > ldd /bin/bash
libcurses.so.1 => /lib/libcurses.so.1
libsocket.so.1 => /lib/libsocket.so.1
libnsl.so.1 => /lib/libnsl.so.1
libdl.so.1 => /lib/libdl.so.1
libc.so.1 => /lib/libc.so.1
libmp.so.2 => /lib/libmp.so.2
/usr/platform/SUNW,UltraSPARC-IIi-cEngine/lib/libc_psr.so.1
You know anyone that might rename one of these libs for any
reason?
I don't..
>> This works fine, uptimes on 99.9x% on all services should
>> proff that...
> Only 99.9%? That's a whole day of downtime per year. ;-)
You missed the 'x' ... most of them are at 99.99% .. and
thats including downtime in service-windows...
Hans Jørgensen
>> Your right .. but, Linux is not that bad a background ..
> using a dynamically linked shell is not a bad idea! I bet
> you install gcc on all of your machines too...
No i don't, but it's installed on my development-machine ...
I build pkg's of everything... and keep 'em on one of our
netapp-filer's...
> Depends on what they do. You can't be an expert in everything.
That's correct...
bit-b...@maney.org
: bit-b...@maney.org wrote:
:> Not a good idea and I doubt that it would do much good anyway.
: It would act as more of a "you have no one to blame but yourself"
: type of warning.
You put nice big warning in the man pages for admintool, passwd, usermod,
vi and vipw. You create one nice big FAQ page for it on sunsolve and
bigadmin. You make pwconv, pwck and grpck gripe and complain about it.
Solves the problem.
:> I'd rather see more of a push to use /usr/ucb/vipw to edit /etc/passwd,
:> as well as error checking routines in /bin/pwconv.
: The trick is to prevent other editors being able to edit it.
: Vi can be changed but Sun don't have any control over third
: party editors. The only other solution is to change /etc/passwd
: into something other than a text file. I don't particularly
: like the idea of that.
No, /etc/passwd needs to remain an ascii text/plain file. And you let
the idiots out there that insist on doing things that they've been
repeatedly told are stupid do the stupid things. It's part of being
an adult.
:> If we are constructing a wish list though, I've got a few to add .....
:>
:> - I'd also like to see much more of a security conscious mindset in
:> the default configurations (disallowing remote root logins, greater
:> password construction controls, fewer services on by default, less
:> reliance on things such as java, etc..).
: The first one is off by default. Fewer services, yes.
I thought so, but I wasn't sure. I haven't used a default Sun build in
so long I've forgotten what one looks like. What about the items on my
list?
:> - I'd like to see Sun implement something like the LED/LCD panel on
:> the front of IBM RS6000 machines for error notification and monitoring
:> of the POST.
: The V880 does have a diagnotic front panel but its hardware
: only. And even then its only some simple stuff but its a
: step in the right direction.
That good to hear.
:> - I'd like to see some actual development done on admintool. If it
:> were even half as good as SMIT/smitty from AIX (including a CLI as
:> well as the GUI), it would make Solaris *much* more attractive to
:> the end-user, while alos allowing for a lot of "protecting the
:> idiots" code to be added in the background.
: I agree with this.
The toughest part I had with the SCSA for Solaris was the questions on
CDE and Admintool, and that was quite simply because I never use either
of them because I work exclusively on servers from a distance and both
of those "tools" flat out suck.
:> - I'd like to see some sort of automatic, standard hot disaster recovery
:> method. It would be nice to have something better than "re-install
:> and restore". Something like mksysb (bootable tape that will recreate
:> the rootvg as it was before the crash, create and layout the filesystems
:> and volume groups and make everything ready for the data restore)
:> from AIX would be wonderful.
: This, of course, assumes that backups have been made. And we all
: know the quality of that assumption.
Fair enough, but if there was a nice hot-bootable-tape method (like
mksysb) available, I don't think it would be too much of a stretch
for everyone to do things like create a /backup volume group and
filesystem that holds backupboot images created by cron on a regular
(nightly?) basis.
Dimitri Maziuk
thus spake Hans Jørgensen:
> Kjetil Torgrim Homme wrote:
>> okay, I think it is bad bad bad that killall on Linux behaves
>> differently than on SVR4. it doesn't impact the usability of the
>> system, but it can give a sysadmin and his users a nasty surprise.
>
> I think that it's pretty dumb that killall acts the way it
> does on SVR4 .. a command that kill's all is meaningless...
Exactly which part of "kill all" escapes you?
Dima
--
We're sysadmins. Sanity happens to other people. -- Chris King
Hans Jørgensen
>>> okay, I think it is bad bad bad that killall on Linux behaves
>>> differently than on SVR4. it doesn't impact the usability of the
>>> system, but it can give a sysadmin and his users a nasty surprise.
>> I think that it's pretty dumb that killall acts the way it
>> does on SVR4 .. a command that kill's all is meaningless...
> Exactly which part of "kill all" escapes you?
None, but killall that does just that with no arguments is
still meaningless :)
Give me one good reason to kill all processes on a system?
Dave Uhring
> Give me one good reason to kill all processes on a system?
>
killall(1M)
Rich Teer
> > fsck assumes that you want to check the whole file system.
>
> Eeh... and that helps you in what way if the /usr-filesystem
> is broken and you can't get to /usr/sbin/fsck ?
I didn't phrase my point very clearly. What I meant was that
by saying what you said, you seemed to be implying that a dead
/usr partition was the only problem. I'm saying that a corrupted
/usr file system is NOT the only problem a statically linked
shell guards against.
> What if someone renames /sbin/sh ?
> What if someone renames /kernel ?
> What if someone without brain runs format?
Fair points. But, /sbin/sh is just one file. ksh relies
on 9 files (I don't install bash, so I can't use it as an
example). That's 9 times the number of potential fsck ups.
> I can't think of why anyone should rename a library bash
> relies on.
It can happen. Let me turn the argument around. Why don't
you want the safest possible root environment? What is wrong
with running bash from within root's .profile, so that if
bash get screwed up, at least you'll still be able to get a
shell?
> haj@pesthest ~ > ldd /bin/bash
> libcurses.so.1 => /lib/libcurses.so.1
> libsocket.so.1 => /lib/libsocket.so.1
> libnsl.so.1 => /lib/libnsl.so.1
> libdl.so.1 => /lib/libdl.so.1
> libc.so.1 => /lib/libc.so.1
> libmp.so.2 => /lib/libmp.so.2
> /usr/platform/SUNW,UltraSPARC-IIi-cEngine/lib/libc_psr.so.1
>
> You know anyone that might rename one of these libs for any
> reason?
Yep.
But whatever. Some people are beyond teaching...
Hans Jørgensen
> It can happen. Let me turn the argument around. Why don't
> you want the safest possible root environment? What is wrong
> with running bash from within root's .profile, so that if
> bash get screwed up, at least you'll still be able to get a
> shell?
Nothing is wrong with that... I just don't think that it's
that wrong changing root's shell ...
Some people in this group seems to think 'changing roots
shell = serious fuckup', it's not that serious, it's very
easy to change.
I think it will take about five minutes to boot in safemode
from our bootserver and change roots shell back in the
unlikely event something destroys bash (at least if it's a
Netra T1;o), and thats including
changing the damaged servers vlan in the switch.
>> haj@pesthest ~ > ldd /bin/bash
>> libcurses.so.1 =3D> /lib/libcurses.so.1
>> libsocket.so.1 =3D> /lib/libsocket.so.1
>> libnsl.so.1 =3D> /lib/libnsl.so.1
>> libdl.so.1 =3D> /lib/libdl.so.1
>> libc.so.1 =3D> /lib/libc.so.1
>> libmp.so.2 =3D> /lib/libmp.so.2
>> /usr/platform/SUNW,UltraSPARC-IIi-cEngine/lib/libc_psr.so.1
>>
>> You know anyone that might rename one of these libs for any
>> reason?
> Yep.
You know strange people.. :)
> But whatever. Some people are beyond teaching...
Well, i learn every day...
Kjetil Torgrim Homme
> Dimitri Maziuk wrote:
> > Exactly which part of "kill all" escapes you?
>
> None, but killall that does just that with no arguments is
> still meaningless :)
>
> Give me one good reason to kill all processes on a system?
how do you do it in Linux? /sbin/killall5 !
(look in /etc/init.d/halt on Red Hat Linux)
Noel R. Nihill
Upon consultation of TFM (TM) we observe the following:
"killall is used by shutdown(1M) to kill all active processes
not directly related to the shutdown procedure."
> --
> Hans Joergensen, http://www.nathue.dk
__________________________
Dimitri Maziuk
thus spake Hans Jørgensen:
You see, Unix, unlike GNU, has design principles.
One of them is that a task is divided into smaller
subtasks, and a separate tool is written for each
subtask (that does one thing only and does it well).
For example, computer shutdown can be subdivided into
following subtasks:
1. synchronize cached files,
2. kill all running processes,
3. power off the computer.
Can you guess where killall fits in? You have 3 tries.
Bonus points for guessing names of the tools that do
the other two.
Dima
--
One distinguishing characteristic of BOFHen is attention deficit disorder.
Put me in front of something boring and I can find a near-infinite number
of really creative ways to bugger off. -- ADB
Hans Jørgensen
>> None, but killall that does just that with no arguments is
>> still meaningless :)
>> Give me one good reason to kill all processes on a system?
> Bonus points for guessing names of the tools that do
> the other two.
Well, you got me ... i never really looked into how Solaris
shuts down .. :o/
(but at least i still miss some good arguments aginst
changing root's shell:)
Roger Marquis
>On 24 Apr 2002, Hans Jørgensen wrote:
>> But, does it really matter if you have a shell thats linked
>> aginst libraries in /usr .. ? you can't get the system
>
>If you worked for me it would: you'd be fired.
Is that why you're out of work Rich while the rest of us aren't?
Militant adherence to sysadmin old-wives-tales is more of a career
problem, especially when any manager can read:
www.roble.com/docs/sol_root_shell.html
>What if someone renames one of the dynamic libraries that
>bash relises on, remotely.
Renaming dynamic libraries, yet another problem that wouldn't be solved
by leaving the root shell at /bin/sh. See:
www.roble.com/docs/sol_root_shell.html#misconception4
--
Roger Marquis
Roble Systems Consulting
http://www.roble.com/
John D Groenveld
Roger Marquis <not-fo...@roble.com> wrote:
>problem, especially when any manager can read:
>
> www.roble.com/docs/sol_root_shell.html
http://www.cse.psu.edu/~groenvel/root-shell.html
John
groe...@acm.org
Rich Teer
Hi Roger,
I was wondering when you'd chime in. :-)
> Is that why you're out of work Rich while the rest of us aren't?
Nope. I see several other knowledgable contributors to this
ng who are also out of work. The fact that I'm in the boonies
in BC, and spenfing most of my time writing a book doesn't
help my short term prospects.
> Militant adherence to sysadmin old-wives-tales is more of a career
> problem, especially when any manager can read:
>
> www.roble.com/docs/sol_root_shell.html
I've read that; most of it is accurate. But not all of it.
> Renaming dynamic libraries, yet another problem that wouldn't be solved
> by leaving the root shell at /bin/sh. See:
>
> www.roble.com/docs/sol_root_shell.html#misconception4
People have refuted that too - but I see you haven't updated
it. For example, who need "ls" when one has "echo *"? And
why don't you mention /usr/sbin/static?
You also don't provide a good answer to the question of
why not just run your shell of choice from root's .profile.
Rob K
@typhoon.sonic.net:
> Is that why you're out of work Rich while the rest of us aren't?
> Militant adherence to sysadmin old-wives-tales is more of a career
> problem, especially when any manager can read:
>
> www.roble.com/docs/sol_root_shell.html
My biggest gripe regarding this stuff isn't necessairly changing root's
shell but it's customizing the root account at all. The more paths you add
to your .profile, .cshrc, etc and the more programs you run at startup tend
to add dependancies that could potential break root when bad things happen.
For exmaple: We had a server where the root account was running
/usr/bin/csh as the shell and root's path referenced all sorts of
convienient directories all over the place, including programs coming from
NFS mounts. Well, one day, this server starting having serious problems
dealing with its NFS server and, because of those dependancies, I was
having a terrible time trying to figure out what was going on because my
shell would just lock up on me. So, I put a policy in that the defaults for
the root account would be the bare minimum's (path set to /usr/bin,
/usr/sbin and nothing else ) with the least intrusive shell, /sbin/sh.
Of course, changing the shell is not a big deal in itself but you have to
be careful not to get root so mucked into the system that it can't perform
when you encounter one of those nasty problems that makes your system only
half useable.
-Rob
Anthony Mandic
> > Yes, that does a certain appeal. I'd try for something
> > to match "GCOS" but I can't get further than "Get a Clue".
>
> How about "Get a Clue Or Screw up"? ;-)
Someone else (who obviously has more sense than to bother
posting to this thread) suggested via email "Gits Change
Our Shell".
-am © 2002
Anthony Mandic
> Nothing is wrong with that... I just don't think that it's
> that wrong changing root's shell ...
There's absolutely no need to either.
> Some people in this group seems to think 'changing roots
> shell = serious fuckup', it's not that serious, it's very
> easy to change.
Its easier to fuck up.
> >> You know anyone that might rename one of these libs for any
> >> reason?
> > Yep.
>
> You know strange people.. :)
Scan back a few weeks worth of posts.
-am © 2002
Rev. Don Kool
> Rich Teer wrote:
>>On Wed, 17 Apr 2002, Michael T Pins wrote:
>>>Not so good advice.
>>>If you are spending so much time as root that /sbin/sh becomes annoying,
>>>you are already doing something wrong. root should only be used for the
>>>things that can only be done as root.
>>>
>>In priciple, I agree. But if you're a professional sysadmin, you'll
>>be doing stuff that can only be done as root most of the time.
>>For example, on a busy mail server, why type
>>
>># makemap dbm virtusertable < virtusertable
>>
>>when
>>
>># r make (or perhaps better, "Esc / make")
>>
>>is available to you?
>>
>>I'm not suggesting for an attosecond that one should treat root
>>as a regular user, though. At the ISP I used to work at, I'd
>>log in as myself to each of their servers, then su - to root.
>>Then, in other windows, I'd do MY stuff, like reading mail,
>>surfing the web and writing documents.
>>
>
> S'funny really, this Unix approach to root use. When I was living in the
> wonderful world of VMS (must seek out a cheap Alpha!), I seemed to spend
> most of my time logged on as SYSTEM, as far as I can remember (it was a
> while ago!)
Why didn't you just "run AUTHORIZE" and modify the limits for your
account? An OpenVMS admin should never have to log in as SYSTEM.
Hope this helps,
Don
--
*********************** You a bounty hunter?
* Rev. Don McDonald * Man's gotta earn a living.
* Baltimore, MD * Dying ain't much of a living, boy.
*********************** "Outlaw Josey Wales"
Anthony Mandic
> : It would act as more of a "you have no one to blame but yourself"
> : type of warning.
>
> You put nice big warning in the man pages for admintool, passwd, usermod,
> vi and vipw. You create one nice big FAQ page for it on sunsolve and
> bigadmin. You make pwconv, pwck and grpck gripe and complain about it.
> Solves the problem.
Not really. It won't stop the Linux wonks and the ACHES arseholes
who think they know everything and can't be bothered reading
any man pages or docs etc. because they just assume it will
be the same as their pathetic excuse for an OS. Unless something
is hardcoded into vi then won't be easily dissuaded. I doubt
they'd even notice a comment.
Hmmm ... does a root entry really need to be there? Can it
be hardcoded into login and su, etc. instead?
> : The only other solution is to change /etc/passwd
> : into something other than a text file. I don't particularly
> : like the idea of that.
>
> No, /etc/passwd needs to remain an ascii text/plain file. And you let
> the idiots out there that insist on doing things that they've been
> repeatedly told are stupid do the stupid things. It's part of being
> an adult.
Yep. Perhaps we should just ignore their posts.
> :> - I'd also like to see much more of a security conscious mindset in
> :> the default configurations (disallowing remote root logins, greater
> :> password construction controls, fewer services on by default, less
> :> reliance on things such as java, etc..).
>
> : The first one is off by default. Fewer services, yes.
>
> I thought so, but I wasn't sure. I haven't used a default Sun build in
> so long I've forgotten what one looks like. What about the items on my
> list?
There are plenty of password controls. There also PAM.
I don't deal too much with Java. I don't think I've seen
too much Java based admin stuff. That's not to say there
may not be any.
> : The V880 does have a diagnotic front panel but its hardware
> : only. And even then its only some simple stuff but its a
> : step in the right direction.
>
> That good to hear.
It could be better though. Even an LED like on the old SSAs
or the display on the Photons would be nice. A numeric diagnostic
display would be passable (you'd need to look up the codes)
but you wouldn't want something too big, so text messages would
probably be minimal too.
> Fair enough, but if there was a nice hot-bootable-tape method (like
> mksysb) available, I don't think it would be too much of a stretch
> for everyone to do things like create a /backup volume group and
> filesystem that holds backupboot images created by cron on a regular
> (nightly?) basis.
How big would these images be? How many would you collect
before culling them thru a cycle? How useful would they
be on disk if you can't get to them? Perhaps they should
go onto a tape backup as the first tape file before the
filesystem dump files.
-am © 2002
Rev. Don Kool
> Kjetil Torgrim Homme wrote:
>
>
>>> I would like to see comments supported in the /etc/passwd file.
>>> The Sun supplied default file could contain one comment after
>>> the root entry informing users not to be stupid.
>>>
>>you may be saying this in jest, but it would be a bad idea to support
>>comments in /etc/passwd due to compatibility with other Unixen.
>>
>
> Compatibility for what? I don't see the need for any here.
You wouldn't, but then you're just a code monkey. Dancy, monkey dance.
LOL!!
Yours in Christ,
Rev. Don Kool
> Daniel Price wrote:
>
>
>>We (some folks in the kernel group) had the same conversation over lunch
>>a few months ago; in particular, we were tired of hearing this tale of woe
>>on comp.unix.solaris.
>>
>
> I think we're all tired of hearing it.
>
>
>>As a result, this is fixed in Solaris 9.
>>
>>Here is the new policy:
>>
>> - If su(1M) (and only su, not login(1)) discovers that it couldn't
>> exec(2) the root user's shell even though the correct password
>> was supplied, it assumes that the root user screwed up the shell;
>> it then goes to "fallback mode" and exec's /sbin/sh.
>>
> ...
>
>> - Simply hard-coding /sbin/sh as the single user mode shell as
>> Wayne suggests above was considered, but that seemed to violate
>> the "principle of least surprise." We could investigate that
>> in the future if problems persist.
>>
>
> I would like to see comments supported in the /etc/passwd file.
> The Sun supplied default file could contain one comment after
> the root entry informing users not to be stupid.
We professional admins don't need that, Tony. It would only help you
code monkeys who have been given root to a development system.
Happy to have cleared things up for you,
Rev. Don Kool
> Wayne Pollock <pol...@acm.org> wrote:
>>Rich Teer wrote:
>>>On 17 Apr 2002, Magesh Ruthrapathy wrote:
>>>>I changed the root shell to /sbin/ksh(which doesnot exist!!) by
>>>>mistake in the /etc/passwd file.Now I am not able to login as root as
>>>>it says the shell doesnt exist.
>>>>
>>>>Is there any way to solve this problem? Please tell me a way other
>>>>than booting the system thru CD.
>>>>
>>>Basically, there isn't. You're SOL.
>>>...
>>>
>>Please forgive a Solaris newbie, but...
>>I've heard this before and I don't quite believe it. Surely there
>>must be an alternative to re-installing:
>>
>>If you boot to single user mode won't Solaris ignore /etc/passwd
>>completely and run some hard-coded shell? If not, can't you login
>>as a regular user and run "su" (with the right arguments) to become
>>super-user without switching shells?
>>
>
> We (some folks in the kernel group) had the same conversation over lunch
> a few months ago; in particular, we were tired of hearing this tale of woe
> on comp.unix.solaris. As a result, this is fixed in Solaris 9.
Hallelujah!! At least one thing is fixed in SOLARIS 9.
Rev. Don Kool
> I changed the root shell to /sbin/ksh(which doesnot exist!!) by
> mistake in the /etc/passwd file.Now I am not able to login as root as
> it says the shell doesnt exist.
>
> Is there any way to solve this problem? Please tell me a way other
> than booting the system thru CD.
If you're running NIS, you could create a UID=0 account (e.g. "root2") on
the NIS master, push the maps and then log in as that. Be sure to
remove it after you're done and re-push the maps.
> The system is Ultra-2 running solaris 2.6.
>
> Thanks for your help inadvance.
No problem.
Hope this helps,
Don
Rev. Don Kool
> [Hans Jørgensen]
>
>
>> Dimitri Maziuk wrote:
>> > Exactly which part of "kill all" escapes you?
>>
>> None, but killall that does just that with no arguments is
>> still meaningless :)
>>
>> Give me one good reason to kill all processes on a system?
>>
>
> how do you do it in Linux? /sbin/killall5 !
>
> (look in /etc/init.d/halt on Red Hat Linux)
So what do you presume LINUX has to do with SOLARIS?
Rev. Don Kool
> Rich Teer wrote:
>
>>It can happen. Let me turn the argument around. Why don't
>>you want the safest possible root environment? What is wrong
>>with running bash from within root's .profile, so that if
>>bash get screwed up, at least you'll still be able to get a
>>shell?
>>
>
> Nothing is wrong with that... I just don't think that it's
> that wrong changing root's shell ...
>
> Some people in this group seems to think 'changing roots
> shell = serious fuckup', it's not that serious, it's very
> easy to change.
Why don't you just create a second UID=0 account with the shell that you
like and leave "root" alone?
Rev. Don Kool
> Rich Teer wrote:
>
>>>I have been working with Solaris for about 2 years now, run
>>>lots of server, and most with bash as roots shell...
>>>
>>Two whole years, eh? Plenty of time to fsck thing up then.
>>I'm betting your background is Linux...
>>
>
> Your right .. but, Linux is not that bad a background ..
Not for hacking PCs in mommy and daddy's basement. For a SOLARIS (or
other UNIX system) admin, it is worse than no background at all.
Hope this helps,
Don
Rev. Don Kool
> bit-b...@maney.org wrote:
[...snip...]
>>- I'd like to see some actual development done on admintool. If it
>>were even half as good as SMIT/smitty from AIX (including a CLI as
>>well as the GUI), it would make Solaris *much* more attractive to
>>the end-user, while alos allowing for a lot of "protecting the
>>idiots" code to be added in the background.
>>
>
> I agree with this.
What Toni, no "ACHES"? ROTFLOLASTD!!!!!!!!
Yours in Christ,
Hans Jørgensen
> Not really. It won't stop the Linux wonks and the ACHES arseholes
> who think they know everything and can't be bothered reading
> any man pages or docs etc. because they just assume it will
> be the same as their pathetic excuse for an OS. Unless something
> is hardcoded into vi then won't be easily dissuaded. I doubt
> they'd even notice a comment.
Let me guess? you are an angry old man? ;)
Linux is - taken the fact that it's mostly a big hack - a
stable - mostly -, fast, secure and most of all cheap OS
that's able to give serious competition to lots of
commercial products, including Solaris.
I have never had a problem with a Linux-based system i could
not fix in less than a day or two ..
You, and other Linux-critics will just have to live with the
fact that Linux is getting better and better every day.
SUN is almost never that fast in solving a problem, at least
not where i'm from...
Don't get me wrong here, i happen to like Solaris, it's a
lot easyer to keep up with and normally runs very good.
> Hmmm ... does a root entry really need to be there? Can it
> be hardcoded into login and su, etc. instead?
That's a lot of hardcoding, and i'll make
backwards-compatibility and compatibility with lots of
opensouce-products breake.. perhaps with a dummy-root in
/etc/passwd .. ?
But i don't see the reason.
> There are plenty of password controls. There also PAM.
> I don't deal too much with Java. I don't think I've seen
> too much Java based admin stuff. That's not to say there
> may not be any.
Uhm .. a tool like Raid Manager... it sure feel's like
java.. :) but i'm not sure.
> It could be better though. Even an LED like on the old SSAs
> or the display on the Photons would be nice. A numeric diagnostic
> display would be passable (you'd need to look up the codes)
> but you wouldn't want something too big, so text messages would
> probably be minimal too.
I for one don't see the need, perhaps a hostname-display on
small servers, i don't get into the server-room's that
often, and sometimes the hostname on the front of our
Netra's get a bit 'out of date' (lots of these small boxes
get used as development-systems for small projects).
Instead monitor errors with BigBrother.. :o)
>> Fair enough, but if there was a nice hot-bootable-tape method (like
>> mksysb) available, I don't think it would be too much of a stretch
>> for everyone to do things like create a /backup volume group and
>> filesystem that holds backupboot images created by cron on a regular
>> (nightly?) basis.
>
> How big would these images be? How many would you collect
> before culling them thru a cycle? How useful would they
> be on disk if you can't get to them? Perhaps they should
> go onto a tape backup as the first tape file before the
> filesystem dump files.
put 'em on NFS? :)
Hans Jørgensen
>> Some people in this group seems to think 'changing roots
>> shell = serious fuckup', it's not that serious, it's very
>> easy to change.
> Why don't you just create a second UID=0 account with the shell that you
> like and leave "root" alone?
Because it does not matter..
But, just for the record.. I'm not the guy who initially
changed root's shell at my compagny.. i just don't see any
reason to change it back...
Hans Jørgensen
>> Your right .. but, Linux is not that bad a background ..
> Not for hacking PCs in mommy and daddy's basement. For a SOLARIS (or
> other UNIX system) admin, it is worse than no background at all.
And your reasons are?
Is it because i don't use admintool but tend to configure
everything with vi ? :)
Benny
>
> Anthony Mandic wrote:
> > Not really. It won't stop the Linux wonks and the ACHES arseholes
> > who think they know everything and can't be bothered reading
> > any man pages or docs etc. because they just assume it will
> > be the same as their pathetic excuse for an OS. Unless something
> > is hardcoded into vi then won't be easily dissuaded. I doubt
> > they'd even notice a comment.
>
> Let me guess? you are an angry old man? ;)
> Linux is - taken the fact that it's mostly a big hack - a
> stable - mostly -, fast, secure and most of all cheap OS
> that's able to give serious competition to lots of
> commercial products, including Solaris.
GNU/Linux is not even close to being as stable as Solaris, and I have
the right to say that because I have used Linux since 1993, a lot longer
than I've been using Solaris in fact.
Linux (I'm talking about the kernel here) IS faster but that is because
some stability was given up on and some speed was won.
GNU/Linux is not secure. Besides, once people will bore of writing
Windows virii Linux will be next, mark my words on this one, there are
so many opportunities to get the Virii in since noone checks the
checksums.
GNU/Linux is very popular because it is very flexible, talks well with
other filesystems and is far more fun to use than Windows, for those
that do not mind going to the learning curve again
In the cheap x86 world, where that Other OS costs almost 1/4th of the
whole machine, Linux has found a good feeding ground and will flourish
but it is neither meat nor fish right now. You can not really use it on
the really big servers and you can not really use it on a workstation
(unless we are talking development, where Linux knowledge is a MUST).
Don't get me wrong either : I pretty much forced my parents to use Linux
in place of Windows and installed it on their box, that way at least I
could sleep easier, since I can do some remote maintenance now, and I
KNOW that if something happens it can never be their fault AND this way
I could automate backups. I have not heard any complaints from them yet
and they've been running on Linux for about 2 years now, I'm sure they
still do not know how to copy a file, but that's okay, they did not know
how to do that on Windows either.
regards,
Benny
--
Disclaimer:
My opinions are not to be confused with those of my employer, Sun
Microsystems.
As in "a cat is not to be confused with a pack of lions". Purrrrrrrrrr.
Hans Jørgensen
>> Let me guess? you are an angry old man? ;)
>> Linux is - taken the fact that it's mostly a big hack - a
>> stable - mostly -, fast, secure and most of all cheap OS
>> that's able to give serious competition to lots of
>> commercial products, including Solaris.
> GNU/Linux is not even close to being as stable as Solaris, and I have
> the right to say that because I have used Linux since 1993, a lot longer
> than I've been using Solaris in fact.
Think i started in '96 or something like that, but still,
Solaris might be more stable, but Linux is stable enough for
production-systems..
One stability-problem SUN has (At least here i Denmark,
don't know the situation in other countries) is that the ppl
that build the machines does not do a very good job.
We had a E6500 with 8(eight!) loose memory-modules, on top
of that SUN was sure it was a software-problem, so it took
like a month to find, and fix the fault.
Out of 60 Netra T1 105 we have had 3 boxes where the
memory-upgrade was not fittet correctly, and sometimes I see
'RED State Exception' when I turn on a box that has been
unused for a while..
The new SunFire-machines might be better, but i'm a bit
nervous when i see the two v880's we recently got running
with CPU-temperatures of about 75-80 degrees celsius.
> In the cheap x86 world, where that Other OS costs almost 1/4th of the
> whole machine, Linux has found a good feeding ground and will flourish
> but it is neither meat nor fish right now. You can not really use it on
> the really big servers and you can not really use it on a workstation
> (unless we are talking development, where Linux knowledge is a MUST).
I have never really used Linux on big servers, only small
1 or 2 cpu-boxes, and inside of an IBM z900-mainframe (The
Linux/390 is allright when it comes to stability, at least 4
times as stable as IBM's (shitty) networkadapters ;o)
Linux is very useable as a workstation when we'r talking
administration of various UNIX'es.
XF86 is a nice and fast interface, even on cheap cards, that
you can't say about SUN, where you'll need very expensive
framebuffers to get acceptable performance.
Benny
> don't know the situation in other countries) is that the ppl
> that build the machines does not do a very good job.
>
> We had a E6500 with 8(eight!) loose memory-modules, on top
> of that SUN was sure it was a software-problem, so it took
> like a month to find, and fix the fault.
Yeah, so that is not good an initial wrong diagnosis can prolong the
time to solution considerably.
It takes some time to train everyone at Sun on these machines, maybe the
case was just handed to an untrained engineer by accident ? I wouldn't
be able to comment on this anyway since I do not know the Case number,
but I would not mind checking it out for you if you provide it to me.
All this has nothing to do with Solaris however, these are hardware
problems.
> XF86 is a nice and fast interface, even on cheap cards, that
> you can't say about SUN, where you'll need very expensive
> framebuffers to get acceptable performance.
Sun servers do not have FrameBuffers, you set your display to any old
box that has one and work there, for real troubleshooting Virtual or
Real terminal servers are a lot more handy.
You shifted the whole discussion to hardware while we were really
talking about Linux vs Solaris, I think that says it all.
Hans Jørgensen
> Sun servers do not have FrameBuffers, you set your display to any old
> box that has one and work there, for real troubleshooting Virtual or
> Real terminal servers are a lot more handy.
I am aware of that :)
I don't think i could live without our
terminalservers, i'd have to get out of my seat a lot more..
:)
> You shifted the whole discussion to hardware while we were really
> talking about Linux vs Solaris, I think that says it all.
Yeb, lets just EOD this subthread..
Hans Jørgensen
> How about changing Solaris so it ignores the 'root' account
> shell field and always uses /sbin/sh?
> ...to allow overiding that, some /etc/system parameter must created.
> set i_am_an_incompetent_admin = 1
If one changes the shell, he/she normally has a reason to.
I don't see a reason to make it harder... simply because a
broken root-shell is an easy problem to recover from, just
like most other problems related to /etc/passwd (like if
it's empty for some reason ;)
Kjetil Torgrim Homme
> Kjetil Torgrim Homme wrote:
>
> > [Hans Jørgensen]
> >
> >> None, but killall that does just that with no arguments is
> >> still meaningless :) Give me one good reason to kill all
> >> processes on a system?
> >>
> > how do you do it in Linux? /sbin/killall5 !
> > (look in /etc/init.d/halt on Red Hat Linux)
>
> So what do you presume LINUX has to do with SOLARIS?
my argument was a bit indirect. Hans Jørgensen didn't see the need
for a "killall" command, and that the Linux "killall" is more useful.
I pointed out that Linux _has_ a killall-command, but they had to
rename it killall5 due to the idiotic (or at least ignorant) naming of
Linux' killall. pgrep/pkill is much preferable, anyway, I hope it
will become a standard tool across Unixen.
--
Kjetil T. [ nerd #4 -- http://nerdquiz.thathost.com ]
Rich Teer
> How about changing Solaris so it ignores the 'root' account
> shell field and always uses /sbin/sh?
>
> ...to allow overiding that, some /etc/system parameter must created.
>
> set i_am_an_incompetent_admin = 1
LOL - I like that one!
Rich Teer
> If one changes the shell, he/she normally has a reason to.
Yeah - but not a GOOD reason to. Incompetance or "Linux does
it" are NOT good reasons.
I can't think of a single good reason to change root's shell,
compared with starting the shell of choice from root's .profile.
> I don't see a reason to make it harder... simply because a
Well, for a start, it would stop the fsckwits coming here,
whining about their broken root account.
Rich Teer
> Solaris might be more stable, but Linux is stable enough for
> production-systems..
LOL!
Dimitri Maziuk
thus spake Kjetil Torgrim Homme:
Hear, hear. Someone choose a poor name for $linux_utility
back when, and so far nobody had enough sense to rename it
to something more appropriate. That's all there is to it.
Dima
--
... with the exception of January and February 1900, all Microsoft application
libraries counted dates the same way.
-- An Interview with Joel Spolsky of JoelonSoftware
Dimitri Maziuk
thus spake Benny:
...
> GNU/Linux is not even close to being as stable as Solaris
That depends. I'm sure Solaris on E4500 is far more
stable than Linux on el-cheapo VIA mobo with crappy
commodity cards. But that is not a meaningful comparison.
> GNU/Linux is not secure.
That's bullshit -- secure OS is the one you know best.
...Besides, once people will bore of writing
> Windows virii Linux will be next, mark my words on this one, there are
> so many opportunities to get the Virii in since noone checks the
> checksums.
That's also bullshit. If you run untrusted binaries as root,
you're asking for it, regardless of the OS.
Bottom line is: if you know to pick the right tool for the job,
it'll work. If you're clueless, you're screwed.
Dima (we run Solaris on servers and Linux on workstations, FWIW)
Dave Uhring
.
>
> Isn't there an NSA Linux variant that's considered secure?
>
> I know the NSA hosts a secure Linux list.
Keeping it secure still requires proper administration.