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@datrix.co.za>
> To: djm@ibs.com.au
> Cc: gem@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@rellim.com Tel:+1(541)382-8588 Fax: +1(541)382-8676
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@datrix.co.za>
> To: djm@ibs.com.au
> Cc: gem@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@rellim.com Tel:+1(541)382-8588 Fax: +1(541)382-8676