[comp.sys.apollo] rlogin not switching to user's home directory

nexus@shogun.cc.umich.edu (Joseph Nowak) (07/28/88)

I am using an Apollo 4000 running SR9.7, Domain/IX 9.5, and TCP/IP 3.1 and I am 
having trouble with rlogin.  When I rlogin, I am placed in the root directory rather
than my home directory (which is /usr/nexus) and I am placed in the bourne shell 
instead of the C shell.  When I login from the console, this problem does not
occur.

Has anyone else run into this problem and found a solution or is this a bug in 
rlogin?
------------------------------------------------------------------------------
 In Real Life:	Joseph Nowak
		Microcomputer Consultant
 		U of M Computing Center User Services
 Via Internet:	nexus@ninja.cc.umich.edu
 Via UUCP:	uunet!umix!ninja.cc.umich.edu!nexus 

 Working for but in no way representing the University of Michigan.
------------------------------------------------------------------------------

kwongj@caldwr.caldwr.gov (James Kwong) (07/28/88)

In article <591@mailrus.cc.umich.edu>, nexus@shogun.cc.umich.edu (Joseph Nowak) writes:
> I am using an Apollo 4000 running SR9.7, Domain/IX 9.5, and TCP/IP 3.1 and I am 
> having trouble with rlogin.  When I rlogin, I am placed in the root directory rather
> than my home directory (which is /usr/nexus) and I am placed in the bourne shell ...(deleted)

I think this might be caused by the /etc/passwd file. Either the passwd file
is missing or maybe it is out of sync because someone changed the registry 
and forgot to run the /etc/crpasswd command to update the passwd file.  
Try running the /etc/crpasswd command or if you are rlogin'ing to an
slave administrative node or a node that has its UNIX stuff linked to the 
slave node,  try running the '/etc/update_slave //master //slave'
after running the /etc/crpasswd on the master node first. 
Also the shell field in the passwd file should have /bin/csh as you shell.
 
You will probably need root permission to do the above. Hope this helps 

JK
-- 
James Kwong  Calif. Depart. of H2O Resources, Sacramento, CA 95802
caldwr!kwongj@ucdavis.edu(Internet) ...!ucbvax!ucdavis!caldwr!kwongj (UUCP)
The opinions expressed above are mine, not those of the State of California or the California Department of Water Resources.

krowitz@RICHTER.MIT.EDU (David Krowitz) (07/28/88)

Sounds like your /etc/passwd file is bad. Look at your installation notes for
Domain/IX again for the info on how to update /etc/passwd after editing the
registry with "edacct" (I believe you run /etc/crpasswd and can then edit the
/etc/passwd file to indicate which shell you want to run).


 -- David Krowitz

krowitz@richter.mit.edu   (18.83.0.109)
krowitz%richter@eddie.mit.edu
krowitz%richter@athena.mit.edu
krowitz%richter.mit.edu@mitvma.bitnet
(in order of decreasing preference)

nielson@dhw68k.cts.com (Mike Nielson) (07/28/88)

In article <591@mailrus.cc.umich.edu>, nexus@shogun.cc.umich.edu (Joseph Nowak) writes:
> I am using an Apollo 4000 running SR9.7, Domain/IX 9.5, and TCP/IP 3.1 and
> I am having trouble with rlogin.  When I rlogin, I am placed in the root
> directory rather than my home directory (which is /usr/nexus) and I am
> placed in the bourne shell instead of the C shell.  When I login from the
> console, this problem does not occur.

When you login directly through the console, the username/password validation
is handled by the registry; when you rlogin, the /etc/passwd file is consulted.
These two databases are not automatically kept in sync with each other.  I
have seen the problem that you described and it was corrected by running
/etc/crpasswd.  After running crpasswd, you may want to check passwd to make
certain that the home directory and startup shell fields are correct.

Mike Nielson
pdaeng!nielson
dhw68k!nielson

weber_w@apollo.COM (Walt Weber) (07/28/88)

In article <591@mailrus.cc.umich.edu> nexus@ninja.cc.umich.edu writes:
>I am using an Apollo 4000 running SR9.7, Domain/IX 9.5, and TCP/IP 3.1 and I am 
>having trouble with rlogin.  When I rlogin, I am placed in the root directory rather
>than my home directory (which is /usr/nexus) and I am placed in the bourne shell 
>instead of the C shell.

1) shell problem:
At 9.7, the unix-derived tcp/ip daemons use /etc/passwd to determine the shell to
invoke -- logins through the display manager create a set of processes based upon
files in `node_data or /sys/dm , and **BY CONVENTION** from a startup file read
from $HOME/user_data (actually ~/user_data).

/etc/passwd is created by /etc/crpasswd, which assigns unix uid/gid numbers
dynamically (a.k.a. dyna-magically).  It leaves the shell field blank.  This may
be edited to the shell of your choice (the sys admin manual for bsd4.2 states this
at the bottom of page 4-23).  Note the caution about editing ONLY this field.

If you edit your entry in /etc/passwd to change the shell, rlogind will invoke the
shell you specify.

2) Home directory:

On Apollo machines, /usr is actually a link to $(systype)/usr -- is it possible that
/usr/nexus exists in /sys5/usr and not in /bsd4.2/usr, and that your default systype
for the NODE is sys5?  When rlogind runs, it runs with a systype of bsd4.2, and if it
doesn't find your home directory at /bsd4.2/usr/nexus, it will leave it set to /.

...walt...
-- 
Walt Weber               PHONE: (617) 256-6600 x7004
Apollo Computer          GENIE: W.WEBER
Chelmsford, People's Republic of Massachusetts

geof@imagen.UUCP (Geoffrey Cooper) (08/01/88)

> If you edit your entry in /etc/passwd to change the shell, rlogind will invoke the
> shell you specify.

I just tried it.  Setting the last field of /etc/passwd to
/bin/start_csh, /bsd4.2/bin/start_csh both end up with the bourne shell
getting executed.  DN3000 running 9.7.1.

BTW, to make rexec work, you have to link /bin to /bsd4.2/bin.  If it
is linked to the usual $(systype)/bin, you can't actually do RCP or
RSH.

I'm not really surprised.

- Geof Cooper
-- 
{decwrl,sun,saber}!imagen!geof

conliffe@CAEN.ENGIN.UMICH.EDU (Darryl C. Conliffe) (08/02/88)

The surprise here is that it didn't work for you.

My /bin => //<node_name>/$(systype)/bin link supports
RCP and RSH just fine.  My /bin/csh in the /etc/passwd starts
a C shell.

Why the snide remark, or is that to cover incompetance?

dennis@PEANUTS.NOSC.MIL (Dennis Cottel) (08/02/88)

Geof Cooper says:
> I just tried it.  Setting the last field of /etc/passwd to
> /bin/start_csh, /bsd4.2/bin/start_csh both end up with the bourne shell
> getting executed.  DN3000 running 9.7.1.

I use /bin/csh in the shell field and it works fine.

> BTW, to make rexec work, you have to link /bin to /bsd4.2/bin.  If it
> is linked to the usual $(systype)/bin, you can't actually do RCP or
> RSH.

I haven't written any programs that use the rexec() call directly,
but the usual link through SYSTYPE works for rsh, as in

   cat file | rsh apollohost sort | crpad

	Dennis Cottel  Naval Ocean Systems Center, San Diego, CA  92152
	(619) 553-1645      dennis@nosc.MIL      sdcsvax!noscvax!dennis

rees@MAILGW.CC.UMICH.EDU (Jim Rees) (08/02/88)

    > If you edit your entry in /etc/passwd to change the shell, rlogind will invoke the
    > shell you specify.
     
    I just tried it.  Setting the last field of /etc/passwd to
    /bin/start_csh, /bsd4.2/bin/start_csh both end up with the bourne shell
    getting executed.  DN3000 running 9.7.1.

But that would be wrong.  You want /bin/csh, not /bin/start_csh.  Don't
forget /etc/crpasswd -map.
-------

krowitz@RICHTER.MIT.EDU (David Krowitz) (08/03/88)

Try checking the node's startup file (`node_data/startup.node_type)
to see that the environment variable SYSTYPE is being set prior
to the start of the Unix daemons. The following lines should be
at the *top* of the file (on older releases, they were at the bottom)


###
###  Select a default UNIX version for the node by uncommenting
###  ONLY ONE of the 'env SYSTYPE' lines:
###
env SYSTYPE 'bsd4.2'
# env SYSTYPE 'sys5'



 -- David Krowitz

krowitz@richter.mit.edu   (18.83.0.109)
krowitz%richter@eddie.mit.edu
krowitz%richter@athena.mit.edu
krowitz%richter.mit.edu@mitvma.bitnet
(in order of decreasing preference)

jwf@wbcs.UUCP (John W. Flaherty) (08/03/88)

In article <1761@imagen.UUCP>, geof@imagen.UUCP (Geoffrey Cooper) writes:
> 
> I just tried it.  Setting the last field of /etc/passwd to
> /bin/start_csh, /bsd4.2/bin/start_csh both end up with the bourne shell
> getting executed.  DN3000 running 9.7.1.
> 
> - Geof Cooper


  A couple months ago, I also noticed the same problem.  With a little looking
  around I found:

    /bin/start_csh  and /bin/start_sh   (BSD) are links to the same file.
    Hmm.
    I created a link called /bin/start_ls,  guess what? it does an ls.
    This makes it obvious that the above program parses through argv[0]
    to figure out what to do. 
    
    I suspect that if there is no argv[0] then /bin/sh is started
    and that when the rlogin fires up the shell it isn't loading argv[0].

    execv(shell,NULL);

NOTE  We were at 9.5 at the time.  We now are at 9.7 and I haven't tried 
      it again.
    
-- 

John Flaherty  
UUCP: ..!ncrwic!wbcs!jwf 
  OR: ..!bcsfse!wbcs!jwf

geof@imagen.UUCP (Geoffrey Cooper) (08/06/88)

OK, I'm much happier, because everybody has yelled and me and we've
finally gotten rlogin and rsh and startup with a csh to work, which we
had not been able to figure out how to do, even after some calls to
apollo.  I don't mind getting flamed in a good cause, thanks for the
help everyone.!

Systype was always being set correctly on every node.  I didn't know
about the bit of running /etc/crpasswd AFTER you modify the password
file.  That sort of makes sense to me now.

If I put /bin/csh in the password entry, everything works well, EXCEPT
incoming rsh, which now says "/bin/csh: invalid argument".  My original
complaint was that it said "/bin/sh: invalid argument", so things are
perhaps better than they were.

If I change the shell listed in the password entry to
"/bsd4.2/bin/csh", EVERYTHING works.

Any ideas?

- Geof
-- 
{decwrl,sun,saber}!imagen!geof