gplan@sun9.aer.com (George Planansky) (04/05/91)
I'd like to use tcsh as root's shell (specified in the passwd file entry). Will that cause me problems? Should I infact stick to sh, or csh, for root? This is on Sun OS 4.03, 4.1.1, and on Alliant Concentrix 5.x . Thank you for your wisdom. -- George Planansky Atmospheric & Environmental Research 840 Memorial Drive, Cambridge, MA 02139 gplanansky@aer.com (617) 547-6207 fax: 661-6479
jik@athena.mit.edu (Jonathan I. Kamens) (04/08/91)
In article <GPLAN.91Apr4220138@sun9.aer.com>, gplan@sun9.aer.com (George Planansky) writes: |> I'd like to use tcsh as root's shell (specified in the passwd file entry). |> Will that cause me problems? I see no problem with this (we do it here). Make sure your tcsh binary is in /etc/shells, though. -- Jonathan Kamens USnail: MIT Project Athena 11 Ashford Terrace jik@Athena.MIT.EDU Allston, MA 02134 Office: 617-253-8085 Home: 617-782-0710
jc@condor.bu.edu (James Cameron) (04/08/91)
>>>>> On 8 Apr 91 03:30:15 GMT, jik@athena.mit.edu (Jonathan I. Kamens) said: jik> In article <GPLAN.91Apr4220138@sun9.aer.com>, gplan@sun9.aer.com (George Planansky) writes: jik> |> I'd like to use tcsh as root's shell (specified in the passwd file entry). jik> |> Will that cause me problems? jik> I see no problem with this (we do it here). Make sure your tcsh binary is jik> in /etc/shells, though. jik> Jonathan Kamens USnail: The only "problem" with using tcsh as the default root shell is that when you want to upgrade your operating system, the new one might not come with tcsh (at least SunOS has yet to do so.) So, just remember to change your shell before the upgrade and things are fine...otherwise root won't be able to log in multi-user. -- -- James Cameron (jc@raven.bu.edu) Signal Processing and Interpretation Lab. Boston, Mass (617) 353-2879 ------------------------------------------------------------------------------ "But to risk we must, for the greatest hazard in life is to risk nothing. For the man or woman who risks nothing, has nothing, does nothing, is nothing." (Quote from the eulogy for the late Christa McAuliffe.)
leif@control.lth.se (Leif Andersson) (04/09/91)
>>>>> On 5 Apr 91 03:01:38 GMT, gplan@sun9.aer.com (George Planansky) said:
George> I'd like to use tcsh as root's shell (specified in the passwd file entry).
George> Will that cause me problems?
George> Should I infact stick to sh, or csh, for root?
I use tcsh as root, but I also play it safe. This is an excerpt from
our passwd file:
root:6rqAa1yzcafwc:0:1:Operator:/:/bin/csh
troot:6rqAa1yzcafwc:0:1:Operator:/usr/local/etc/root:/usr/local/bin/tcsh
In this way I can almost always log in as troot and use tcsh for
normal system administration. In case of trouble or in special cases I
can log in as root and get csh. As you can see the uid and the
password is the same. I have seen no ill effects from this. The two
accounts have different home directories, because the troot home is
NFS-mounted on all our workstations. Saves a lot of administration.
-------------------------------------------------------------------------------
Leif Andersson Internet: leif@Control.LTH.Se
Dept. of Automatic Control Bitnet: BODELA@SELDC51
Lund Institute of Technology Phone: +46 46 109742
P.O. Box 118 Fax: +46 46 138118
S-221 00 Lund, Sweden
-------------------------------------------------------------------------------hamilton@kickapoo.cs.iastate.edu (Jon Hamilton) (04/09/91)
jc@condor.bu.edu (James Cameron) writes: >>>>>> On 8 Apr 91 03:30:15 GMT, jik@athena.mit.edu (Jonathan I. Kamens) said: >jik> In article <GPLAN.91Apr4220138@sun9.aer.com>, gplan@sun9.aer.com (George Planansky) writes: >jik> |> I'd like to use tcsh as root's shell (specified in the passwd file entry). >jik> |> Will that cause me problems? >jik> I see no problem with this (we do it here). Make sure your tcsh binary is >jik> in /etc/shells, though. >jik> Jonathan Kamens USnail: >The only "problem" with using tcsh as the default root shell is that >when you want to upgrade your operating system, the new one might not >come with tcsh (at least SunOS has yet to do so.) So, just remember >to change your shell before the upgrade and things are fine...otherwise >root won't be able to log in multi-user. On my machine (running A/UX), if your login shell can't be started for some reason (disk not mounted or file not present, whatever), you get a message to the effect "can't exec /usr/local/bin/tcsh, exec'ing /bin/sh instead.", and it proceeds to start the bourne shell instead. This only occurs for root. >-- > -- James Cameron (jc@raven.bu.edu) >Signal Processing and Interpretation Lab. Boston, Mass (617) 353-2879 >------------------------------------------------------------------------------ >"But to risk we must, for the greatest hazard in life is to risk nothing. For >the man or woman who risks nothing, has nothing, does nothing, is nothing." > (Quote from the eulogy for the late Christa McAuliffe.) -- Jon Hamilton hamilton@kickapoo.cs.iastate.edu " I feel a lot more like I do now that I did before I got here " - can't remember who
christos@theory.tn.cornell.edu (Christos S. Zoulas) (04/09/91)
In article <JC.91Apr8024148@condor.bu.edu> jc@condor.bu.edu (James Cameron) writes: >The only "problem" with using tcsh as the default root shell is that >when you want to upgrade your operating system, the new one might not >come with tcsh (at least SunOS has yet to do so.) So, just remember >to change your shell before the upgrade and things are fine...otherwise >root won't be able to log in multi-user. > Yeah, this is one of the problems. The main problem though for a root account is that in most cases it has to be shared by more than one people. Everyone has different preferences for aliases and $variables, and this makes it difficult to share the account. We try to solve the problem by keeping only the minimum setup in /.cshrc and do the rest in our own .cshrc. In the setup we have here we only login as root in case of emergency, otherwise we use su. The default root shell is csh, but we have the following in /.cshrc: # # When we exec tcsh on an su # we source the person's .cshrc, and we make our home # be the person's home. # if ( $?tcsh ) then if ( $HOSTTYPE != "hp9000s300" ) then set me = `who am i | awk -F\! '{ print $2 }'` else set me = `who am i` endif if ( $me[1] != "root" ) then set home = `ypmatch $me[1] passwd | awk -F: '{ print $6 }'` source $home/.cshrc endif endif .... alias et exec tcsh In my personal .cshrc I have a section which is executed when $uid == 0. This changes the prompt, and removes dot from the path, and aliases rm to rm -i etc... In that way everyone who has root priviledges gets his own aliases and working environment. So I just need to type 'et' after I su, and there I feel right at home... christos -- +------------------------------------------------------------------------+ | Christos Zoulas | 389 Theory Center, Electrical Engineering, | | christos@ee.cornell.edu | Cornell University, Ithaca NY 14853. | | christos@crnlee.bitnet | Phone: (607) 255 0302 | Fax: (607) 254 4565 |
moore@srl.mew.mei.co.jp (W. Phillip Moore) (04/09/91)
Jonathan> I see no problem with this (we do it here). Make sure your tcsh
Jonathan> binary is in /etc/shells, though.
That and make sure the binary is local, not accessed by NFS. One nearby
site made the error of make /usr/local/bin/bash the root shell. Fine,
except that /usr/local is a shared NFS directory. When the NFS server was
down, he couldn't login as root.
On our system, all shells are in /bin.
W. Phillip Moore Phone: 06-908-1431
UNIX/Network System Administrator FAX: 06-906-7251
Semiconductor Research Laboratory E-mail: moore@mew.mei.co.jp
Matsushita Electric Works, Ltd. 1048 Kadoma, Osaka 571, Japanflee@cs.psu.edu (Felix Lee) (04/09/91)
># When we exec tcsh on an su ># we source the person's .cshrc, and we make our home ># be the person's home. There's a simpler and faster way than all that `who am i` `ypmatch` `awk` nonsense, given that $USER is something sane. set home = ~$user This will fail abominably if $user isn't set, so it should probably be protected with an if statement. Something like: if (! $?user && $?LOGNAME) set user = $LOGNAME if (! $?user) set user = root set home = ~$user -- Felix Lee flee@cs.psu.edu
dermoudy@sol.surv.utas.edu.au (Julian Dermoudy) (04/10/91)
moore@srl.mew.mei.co.jp (W. Phillip Moore) writes: >Jonathan> I see no problem with this (we do it here). Make sure your tcsh >Jonathan> binary is in /etc/shells, though. >That and make sure the binary is local, not accessed by NFS. One nearby >site made the error of make /usr/local/bin/bash the root shell. Fine, >except that /usr/local is a shared NFS directory. When the NFS server was >down, he couldn't login as root. >On our system, all shells are in /bin. If I'm not mistaken, saying that "the binary is local" is an understatement. In fact, root's shell should be on either the root partition or the /usr partition, because (atleast on Suns) when you boot singleuser these are the only partitions mounted. I'm unsure what will happen if root's shell isn't on one of these partitions, you would certainly get the "No Shell" error message (or similar) but whether it would default to the Bourne shell or simply log you off again, I wouldn't know. -Julian. -- Julian Dermoudy AARNet: J.R.Dermoudy@censis.utas.edu.au Centre for Spatial Info. Studies, 'Phone: +61 02 202108 University of Tasmania, Fax : +61 02 240282 GPO Box 252C Hobart, Tasmania, AUSTRALIA, 7001.
cudcv@warwick.ac.uk (Rob McMahon) (04/11/91)
In article <MOORE.91Apr9131053@terra.srl.mew.mei.co.jp> moore@srl.mew.mei.co.jp (W. Phillip Moore) writes: >That and make sure the binary is local, not accessed by NFS. I'd also add to make sure it's statically linked. If you goof and mess up the shared library stuff (e.g. by doing ldconfig /non/existent/directory ...) you might appreciate still being able to get a root shell ... Cheers, Rob -- UUCP: ...!mcsun!ukc!warwick!cudcv PHONE: +44 203 523037 JANET: cudcv@uk.ac.warwick INET: cudcv@warwick.ac.uk Rob McMahon, Computing Services, Warwick University, Coventry CV4 7AL, England