Yo Andrew! What version of Openssh are you trying? RGDS GARY On Mon, 12 Jun 2000, Andrew McGill wrote:> Date: Mon, 12 Jun 2000 15:26:53 +0200 > From: Andrew McGill <andrewm at datrix.co.za> > To: djm at ibs.com.au > Cc: gem at rellim.com > Subject: Openssh on SCO Openserver Release 5 > > Hi there > > Your e-mail address appears in the README for openssh, which is why I am > sending this to you. (I hope you are somewhere close to the maintainers of > openssh) > > I have managed to compile and run openssh on SCO Openserver (another > version from the original port). There were a few funnies which you may > want to incorporate into the distribution: > > 0. System information: > > $ uname -X > System = SCO_SV > Node = scosysv > Release = 3.2v5.0.4 > KernelID = 97/05/07 > Machine = Pentium > BusType = ISA > Serial = 4FC006928 > Users = 16-user > OEM# = 0 > Origin# = 1 > NumCPU = 1 > > > 1. /dev/ptmx > > config.h > My SCO does support the device /dev/ptmx after a fashion, but does not > enable them as true tty's. This causes problems with sshd. The man page > says: > >>> > Limitations > ==========> > Although /dev/ptmx is referred to as a pseudo-tty, the master device does > not have tty characteristics and therefore cannot become the controlling > tty of a process group. The slave side of the connection does have the > characteristics of a real tty and can become the controlling tty of a > process group. > <<< > > I changed the config.h line > #define HAVE_DEV_PTMX 1 > to contain the following > /* #define HAVE_DEV_PTMX 1 */ > fixes this. I think the correct approach is to fix configure.in to include > a line for SCO similar to the line for linux --but installing autoconf on > this box doesn't seem like fun at the moment, especially since I am > changing jobs within the month: > > *-*-sco3*) > no_dev_ptmx=1 > ;; > > 2. MAXPATHLEN > > include.h > My SCO header files do not define the MAXPATHLEN macro, which is required > by openssh. To rectify this, I added the following lines before the final > endif: > #ifndef MAXPATHLEN > #define MAXPATHLEN 64 > #endif > According to usr/include/limits.h, the correct SCO value appears to be > PATH_MAX -- except it is not defined either :( > > host system type: > i586-pc-sco3.2v5.0.4 > > > > --- > This entire communication can be represented as a binary integer. As a > result it is entirely rational. > > >--------------------------------------------------------------------------- Gary E. Miller Rellim 20340 Empire Ave, Suite E-3, Bend, OR 97701 gem at rellim.com Tel:+1(541)382-8588 Fax: +1(541)382-8676
Hi! - I guess I should have said. The versions are: openssh-2.1.1p1 openssl-0.9.5a zlib-1.1.3 perl-5.6.0 &:-) ----- Original Message ----- From: <gem at rellim.com> To: Andrew McGill <andrewm at datrix.co.za> Cc: Sent: Monday 12 June 2000 18:33 Subject: Re: Openssh on SCO Openserver Release 5 Yo Andrew! What version of Openssh are you trying? RGDS GARY On Mon, 12 Jun 2000, Andrew McGill wrote:> Date: Mon, 12 Jun 2000 15:26:53 +0200 > From: Andrew McGill <andrewm at datrix.co.za> > To: djm at ibs.com.au > Cc: gem at rellim.com > Subject: Openssh on SCO Openserver Release 5 > > Hi there > > Your e-mail address appears in the README for openssh, which is why I am > sending this to you. (I hope you are somewhere close to the maintainersof> openssh) > > I have managed to compile and run openssh on SCO Openserver (another > version from the original port). There were a few funnies which you may > want to incorporate into the distribution: > > 0. System information: > > $ uname -X > System = SCO_SV > Node = scosysv > Release = 3.2v5.0.4 > KernelID = 97/05/07 > Machine = Pentium > BusType = ISA > Serial = 4FC006928 > Users = 16-user > OEM# = 0 > Origin# = 1 > NumCPU = 1 > > > 1. /dev/ptmx > > config.h > My SCO does support the device /dev/ptmx after a fashion, but does not > enable them as true tty's. This causes problems with sshd. The man page > says: > >>> > Limitations > ==========> > Although /dev/ptmx is referred to as a pseudo-tty, the master devicedoes> not have tty characteristics and therefore cannot become thecontrolling> tty of a process group. The slave side of the connection does have the > characteristics of a real tty and can become the controlling tty of a > process group. > <<< > > I changed the config.h line > #define HAVE_DEV_PTMX 1 > to contain the following > /* #define HAVE_DEV_PTMX 1 */ > fixes this. I think the correct approach is to fix configure.in toinclude> a line for SCO similar to the line for linux --but installing autoconf on > this box doesn't seem like fun at the moment, especially since I am > changing jobs within the month: > > *-*-sco3*) > no_dev_ptmx=1 > ;; > > 2. MAXPATHLEN > > include.h > My SCO header files do not define the MAXPATHLEN macro, which is required > by openssh. To rectify this, I added the following lines before thefinal> endif: > #ifndef MAXPATHLEN > #define MAXPATHLEN 64 > #endif > According to usr/include/limits.h, the correct SCO value appears to be > PATH_MAX -- except it is not defined either :( > > host system type: > i586-pc-sco3.2v5.0.4 > > > > --- > This entire communication can be represented as a binary integer. As a > result it is entirely rational. > > >--------------------------------------------------------------------------- Gary E. Miller Rellim 20340 Empire Ave, Suite E-3, Bend, OR 97701 gem at rellim.com Tel:+1(541)382-8588 Fax: +1(541)382-8676