HI, thanks!

On Fri, Feb 13, 2009 at 3:11 PM, Mike Kazantsev
<[email protected]> wrote:
> On Fri, 13 Feb 2009 13:15:12 +0800
> Chuanwen Wu <[email protected]> wrote:
>
>> Could you please give more details? How to change it to something
>> default?
>
> Well, that's pretty much the basics...
> Shells for each system user are defined in /etc/passwd, which should be
> edited by 'vipw' command.
>
> What I've meant is the case, when you, or something else changed
> '/etc/passwd', replacing '/bin/bash' with something like
> '/sbin/nologin' or some other path, which is not a valid shell.
Hi, here is the root infomation in my /etc/passwd:

root:x:0:0:root:/root:/bin/bash

>
> Actually, ssh shouldn't work with invalid shell like that as well, but
> one, for example, can add some commands to ".bashrc" which will work
> only in ssh environment (using some env vars, set by ssh, for example).
>
> Then, there might be some ssh-only shell, so I'd suggest to set shell
> to '/bin/sh' (which is actually bash, for gentoo) and disable all the
> configs it's using, like '~/.bashrc' or '/etc/bashrc' (see 'man bash',
> for full list).
In the /root, there is no .bashrc, and in other users' home, the
.bashrc is normal:
/*******************************************
$ cat /home/wcw/.bashrc
# /etc/skel/.bashrc
#
# This file is sourced by all *interactive* bash shells on startup,
# including some apparently interactive shells such as scp and rcp
# that can't tolerate any output.  So make sure this doesn't display
# anything or bad things will happen !


# Test for an interactive shell.  There is no need to set anything
# past this point for scp and rcp, and it's important to refrain from
# outputting anything in those cases.
if [[ $- != *i* ]] ; then
        # Shell is non-interactive.  Be done now!
        return
fi


# Put your fun stuff here.
/*****************************************************/

> Also, Neil has made a good point that there might be something
> in /etc/profile, which is usually sourced by all bash-like shells.
Here is my /etc/profile, which I think is normal, too:
/*****************************************************/
# cat /etc/profile
# /etc/profile: login shell setup
#
# That this file is used by any Bourne-shell derivative to setup the
# environment for login shells.
#

# Load environment settings from profile.env, which is created by
# env-update from the files in /etc/env.d
if [ -e /etc/profile.env ] ; then
        . /etc/profile.env
fi

# 077 would be more secure, but 022 is generally quite realistic
umask 022

# Set up PATH depending on whether we're root or a normal user.
# There's no real reason to exclude sbin paths from the normal user,
# but it can make tab-completion easier when they aren't in the
# user's PATH to pollute the executable namespace.
#
# It is intentional in the following line to use || instead of -o.
# This way the evaluation can be short-circuited and calling whoami is
# avoided.
if [ "$EUID" = "0" ] || [ "$USER" = "root" ] ; then
        
PATH="/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:${ROOTPATH}"
else
        PATH="/usr/local/bin:/usr/bin:/bin:${PATH}"
fi
export PATH
unset ROOTPATH

# Extract the value of EDITOR
[ -z "$EDITOR" ] && EDITOR="`. /etc/rc.conf 2>/dev/null; echo $EDITOR`"
[ -z "$EDITOR" ] && EDITOR="/bin/nano"
export EDITOR

if [ -n "${BASH_VERSION}" ] ; then
        # Newer bash ebuilds include /etc/bash/bashrc which will setup PS1
        # including color.  We leave out color here because not all
        # terminals support it.
        if [ -f /etc/bash/bashrc ] ; then
                # Bash login shells run only /etc/profile
                # Bash non-login shells run only /etc/bash/bashrc
                # Since we want to run /etc/bash/bashrc regardless, we source it
                # from here.  It is unfortunate that there is no way to do
                # this *after* the user's .bash_profile runs (without putting
                # it in the user's dot-files), but it shouldn't make any
                # difference.
                . /etc/bash/bashrc
        else
                PS1='\...@\h \w \$ '
        fi
else
        # Setup a bland default prompt.  Since this prompt should be useable
        # on color and non-color terminals, as well as shells that don't
        # understand sequences such as \h, don't put anything special in it.
        PS1="`whoa...@`uname -n | cut -f1 -d.` \$ "
fi

for sh in /etc/profile.d/*.sh ; do
        if [ -r "$sh" ] ; then
                . "$sh"
        fi
done
unset sh
/*****************************************************/
>
> Syslog usually uses '/var/log/messages' as a collector for everything
> that is being sent to it, so I'd check that file first. And make sure
> the timestamps there are recent - it should mean that syslog is writing
> to it and is not dead.
I got the login information below from the tail of /var/log/messages:
/********************************************/
Feb 13 15:47:18 Gentoo-F304-Server login[5735]:
pam_unix(login:session): session opened for user root by LOGIN(uid=0)
Feb 13 15:47:18 Gentoo-F304-Server login[15097]: ROOT LOGIN  on 'tty1'
Feb 13 15:47:18 Gentoo-F304-Server login[5735]:
pam_unix(login:session): session closed for user root
Feb 13 15:48:21 Gentoo-F304-Server login[15099]:
pam_unix(login:session): session opened for user wcw by LOGIN(uid=0)
Feb 13 15:48:21 Gentoo-F304-Server login[15099]:
pam_unix(login:session): session closed for user wcw
Feb 13 15:50:01 Gentoo-F304-Server cron[15469]: (root) CMD (test -x
/usr/sbin/run-crons && /usr/sbin/run-crons )
Feb 13 15:50:01 Gentoo-F304-Server cron[15477]: (root) CMD (root^Itest
-x /usr/sbin/run-crons && /usr/sbin/run-crons )
Feb 13 15:50:45 Gentoo-F304-Server sshd[15531]: Accepted
keyboard-interactive/pam for wcw from 192.168.1.7 port 59220 ssh2
Feb 13 15:50:45 Gentoo-F304-Server sshd[15534]:
pam_unix(sshd:session): session opened for user wcw by (uid=0)
/********************************************/

The first two logins, which the timestamps are Feb 13 15:48:21 and Feb
13 15:50:01, is from the terminal. And the last one is from ssh.

> 'dmesg' command is usually a good source for failure messages too, but
> only on kernel level (when something really nasty happens). There might
> be some segfaults, produced by your shell, and usually indicate
> programming or compilation errors.
>
> --
> Mike Kazantsev // fraggod.net
>
>
Thanks for your patience and help!


-- 
wcw

Reply via email to