Subject: Re: Pine, rimapd, and UnixWare...

From: [email-masked] (Barry Bouwsma)
Date: 8 Dec 1995 04:41:59 GMT

In a previous article, [email-masked] (Andrew Josey) says:

>:     I am attempting to use Pine3.91 for UnixWare, presumably obtained
>: from the usle archives at ftp.novell.de or equivalent, as an IMAP and
>: SMTP client program.  This should be attempting to execute the command:
>: rsh IMAPHOST exec /etc/rimapd
>
>This looks like a TCP/IP issue not Pine.

    I don't think so -- I can successfully execute this command entered
by hand at the shell prompt right before starting Pine, which apparently
meets with failure, or else seems not to call the rsh.

    Is it possible that Pine might be trying the restricted shell?

    Has anybody successfully used Pine this way (passwordless authentication)
with a remote IMAP server from UnixWare?

Thanks...
-- 
 Barry Bouwsma, Mendel University Brno, Czech Republic -- I Still Have No Life
Flash!  Seeking work with computers over winter in Czech or Slovak Republic...
(or Austria, Switzerland, Germany...)    send offers to  <[email-masked]>
This sig is five lines long.  Check your newsreader configuration if you do not

---

From: [email-masked] (Barry Bouwsma)
Date: 7 Dec 1995 11:06:33 GMT

Seeking out-of-the-box-compiled Pine3.91 for UnixWare...

    I am attempting to use Pine3.91 for UnixWare, presumably obtained
from the usle archives at ftp.novell.de or equivalent, as an IMAP and
SMTP client program.  This should be attempting to execute the command:
rsh IMAPHOST exec /etc/rimapd

    I am successful with Pine on other platforms.  I am able to make the
connection with no need to enter username and password, but when making
the connection from the pre-compiled UnixWare version, I am always asked
for login name and password.  I'm trying to migrate to a client-server
model with one central host handling all the mail instead of spreading
the delivery across many machines.  (Yes, being asked to debug the fourth
vendor-supplied version of sendmail.cf was too much.)

    From this UnixWare host, I am able to manually enter the command above
and receive the PREAUTH login, meaning it *should* work from Pine.  Also,
using Pine from another machine meets with success, so my suspicion was
that the UnixWare Pine was somehow not attempting this command.  (No, with
no compiler here, I can't compile, and the idea behind the UnixWear server
is that it's a plug-and-pray machine requiring as little administration
as possible.)

    On the imaphost machine, the tcp_wrapper package is running, logging
these rsh connections or attempts.  So, I decided I would look at the log
of connects, since the Pine debug file, even at level 9, shows no indication
of the failure of the rsh attempt.

    My manual rsh attempts are logged from the machine.  But when I try to
run Pine on the same machine, there is nothing logged.  This leads me to
strongly suspect that the UnixWare version does not attempt the rsh for
preauthenticated login, and instead goes straight to the port 143 connect
with manual login and password entry.

    Can somebody confirm this?  And better, can someone provide a pointer
to a binary of Pine which will run on UnixWare 1.1.4 and will attempt this
rsh login?

       Your help would be greatly appreciated -- without this, this school will
stick to having every host handle its own mail, with totally different
sendmails, and a much bigger administrative headache...

Thanks...

---

From: [email-masked] (Andrew Josey)
Date: Thu, 07 Dec 1995 14:16:40 GMT

Barry Bouwsma ([email-masked]) wrote:

: Seeking out-of-the-box-compiled Pine3.91 for UnixWare...

Andrew

---

From: [email-masked] (Barry Bouwsma)
Date: 17 Dec 1995 13:55:04 GMT

> rsh IMAPHOST exec /etc/rimapd

    Okay, so I'm still struggling with this, but with a little bit more 
information so I've made a small bit of progress.

    Thanks to private e-mail from Mark Crispin, it was pointed out that
this UnixWare version (which I'm running on UnixWare1.1.4) is based on the
SV4 port of Pine.  What that means is that the command it expects to find
to exec the /etc/rimapd, as defined in the c-client Makefile, is
/usr/bin/resh (remote shell, no doubt to differentiate from the restricted
shell which would be rsh), and not /usr/bin/rsh . 

    If I look at /usr/bin on this UnixWare system, I find rsh, which 
indeed is the remote shell, but no resh.

    For the sake of a UnixWare port, or at least definitions which would 
point in such a direction, I ask, does the standard UW1.x consist of 
/usr/bin/rsh but no /usr/bin/resh for the remote shell?
    Is there any difference in UW2.x , or is /usr/bin/rsh still what a 
SysVR4 system would know as /usr/bin/resh?

    Okay.  Now the fun began.  So, I thought, aha, well, let's make a 
/usr/bin/resh which Pine expects to be able to execute, which I did by 
linking /usr/bin/rsh to it.  One slight drawback -- if rsh is called by 
any other name, that is taken as a host for the argument to rlogin.  So I 
got messages to the effect that resh was an unknown host.

    The True Hacker does not give up, but says aha -- so I alias the host 
called resh to be our IMAP server.  Okay, all well and good, and the 
command ``/usr/bin/resh'' would log one into the IMAP server.  
Unfortunately, the command ``/usr/bin/resh IMAPSERVER exec /etc/rimapd'' 
was not successful.  Sigh.

    The True Hacker does not give up.  I am not The True Hacker.  I chose 
to turn my attention to other more rewarding things, and planned to attack 
the problem at the source (code).

    When I got my courage up again, I decided to see if I might be able 
to compile Pine with a change to the definition of RSH so it would try to 
execute /usr/bin/rsh instead.  This is not so easy.  The UnixWear box I'm 
trying to get this to work on has no compiler, and a limited amount of 
space like everything else around here.  So, I am looking at the 
following options:

1)  Begging and pleading for someone with a compiler for UnixWare1.1.4 
(or compatible) to recompile Pine with the noted change to point Pine in 
the right direction to find /usr/bin/rsh .  If any other changes are 
needed, report them to the Pine Team for possible inclusion as a UW1 port 
-- if UW2 is the same and has no resh, then perhaps there can be a UW2 
port as well if it is different from UnixWare1.x .  I have no chance of 
getting a compiler here, so I have no way to do this myself.

2) Building gcc on another system as a cross-compiler and using that to
compile Pine for i386-sysv4 UnixWare.  This is the approach I've decided
to try just for laughs and see how it works.  Of course, my resources here
are limited and I've spent the weekend doing this, which is more time than
I promised myself I'd put into it.  Kinda hard to install a cross-compiler
and supporting utilities when you don't have root access, but The True
Hacker is not discouraged by such petty limitations.  Nor is The True
Hacker put off by certain header files which are called for by Pine but
which I haven't seen on the UnixWhereAreThey box.  I am not The True
Hacker.  But at least I gain experience and understanding.  Well,
experience. 

3)  Asking someone to put me out of my misery.  If you're in the Brno 
area, you can find me at Mendel University, if I'm not walking downtown 
muttering about includes.  But only until Wednesday, which is when I hope 
to have this problem solved, for I'll go on my way and let them hack the 
sendmail.cf rather than migrate to a client-server model.

4) Using a friendly binary file editor to change the resh references,
which can be seen by running ``strings'' on the Pine binary and grepping
(see http://www.vszbr.cz/~guest/images/grep.gif) for ``resh'' on the
output of that, into references to /usr/bin/rsh and rsh and Ed Grshko.  I
don't really know what I'm doing here, nor do I know if it's the correct
approach, but it's less painful than option 2, and while I can't tell if
it works until Monday when I have access to the machines of interest, the
resulting binary doesn't quite exactly bomb immediately just yet as far as
I can tell, I think, maybe. 

5) Skip the problem, let someone else deal with it, open a fine Czech beer
or three, turn up the heat, play some Jungle and Breakbeat loud, and enjoy
the weekend. 

    As always, I would be grateful for any help someone can offer, advice 
about what you've done in similar situations, or consolation.

Many thanks...

---

From: [email-masked] (Michael J Matthews)
Date: 19 Dec 1995 22:25:13 GMT

>shell which would be rsh), and not /usr/bin/rsh . 

SYSV remote shell used to be called remsh NOT resh. I guess that has been
Berkleyized to rsh. I wonder what happened to SV restricted shell (rsh)?

-- 
/*---------------------------------------------------*/
Michael J Matthews		[email-masked]

---

From: [email-masked] (Andrew Josey)
Date: Thu, 21 Dec 1995 11:59:22 GMT

Barry Bouwsma ([email-masked]) wrote:
: On 7 Dec 1995, Barry Bouwsma wrote:
: >     I am attempting to use Pine3.91 for UnixWare, presumably obtained
: > from the usle archives at ftp.novell.de or equivalent, as an IMAP and
: > SMTP client program.  This should be attempting to execute the command:
: > rsh IMAPHOST exec /etc/rimapd
:     Okay, so I'm still struggling with this, but with a little bit more 
: information so I've made a small bit of progress.
:     Thanks to private e-mail from Mark Crispin, it was pointed out that
: this UnixWare version (which I'm running on UnixWare1.1.4) is based on the
: SV4 port of Pine.  What that means is that the command it expects to find
: to exec the /etc/rimapd, as defined in the c-client Makefile, is
: /usr/bin/resh (remote shell, no doubt to differentiate from the restricted
: shell which would be rsh), and not /usr/bin/rsh . 
:     If I look at /usr/bin on this UnixWare system, I find rsh, which 
: indeed is the remote shell, but no resh.

I have recompiled the c-client directory on UW1.1 to use rsh instead
of resh . I'll place the updated binaries in a bin.tar file, 
pine-3.91.supp.bin.tar.Z on ftp.novell.co.uk:/pub/unixware/usle/mailtools.

:     For the sake of a UnixWare port, or at least definitions which would 
: point in such a direction, I ask, does the standard UW1.x consist of 
: /usr/bin/rsh but no /usr/bin/resh for the remote shell?
:     Is there any difference in UW2.x , or is /usr/bin/rsh still what a 
: SysVR4 system would know as /usr/bin/resh?

SVR4 has always has /usr/bin/rsh for the remote shell, the restricted
shell got moved to /usr/lib/rsh.

--
Andrew Josey, Email: [email-masked] 	#include <std/disclaimer.h>

---

From: [email-masked] (Dan Busarow)
Date: Thu, 21 Dec 1995 20:16:43 GMT

/usr/bin/rsh is the remote shell
/usr/lib/rsh is the restricted shell.

/usr/bin/resh is probably UW's or the porter's local convention, not SYSV's

Dan
--
 Dan Busarow
 DPC Systems
 Dana Point, California

---

From: [email-masked] (Steve Ward)
Date: 21 Dec 1995 17:05:19 -0800

In article <[email-masked]>,
>Berkleyized to rsh. I wonder what happened to SV restricted shell (rsh)?

Actually, I've seen both (on different SVR3.2 ports).

As I recall, the 'r' commands came from BSD, and the new name was created
by the SysV people just to keep it from colliding with the restricted
shell (now /usr/lib/rsh).

Steve
-- 
Steve Ward, Jr., Advanced Systems Specialist
School of Engineering, University of Portland
Portland OR
[email-masked]

---

From: Mark Crispin <[email-masked]>
Date: Wed, 20 Dec 1995 16:02:12 -0800

> Berkleyized to rsh. I wonder what happened to SV restricted shell (rsh)?

Hmm.  I have HP-UX and SVR2 using /usr/bin/remsh; and PTX and SVR4 using
/usr/bin/resh.  SVR2 is represented by an ATT Unix PC (3B1 or 7300); I'm
not sure what SVR4 represents.

Other interesting ones are /usr/bin/restsh on Data General, /usr/bin/rsh
on AIX on PowerPC, Altos, BSDI, ICL DRS/NX, Linux, NetBSD, SGI, and
Solaris; /bin/rsh on AIX on RT; and /usr/bin/rcmd on SCO.

Everything else is /usr/ucb/rsh.

Much of this information is hearsay, and needs to be taken with a grain of
salt.

-- Mark --

DoD #0105, R90/6 pilot, FAX: (206) 685-4045  ICBM: N 47 39'35" W 122 18'39"
Science does not emerge from voting, party politics, or public debate.