New OpenSSH packages available (3.1p1)
Roberto Zini
Last night I was kindly informed by Bela that a new version of
OpenSSH had come out so today I decided to give it a run in order
to provide you with some new packages to use under OpenServer5.
The new version if 3.1p1 and is available at the following URL
(along with previous ones):
ftp://ftp.strhold.it/sco_security
I've also updated the README.ssh file so give it a read before
installing the software.
A couple of notes (and PLEASE read'em carefully before downloading):
1) it seems that there's a typo in a 'C' module which prevents the
package from bein correctly compiled. In fact, in compat.c, you
can find a reference to
SSH_BUG_PKAQTH
which is not defined anywhere on the distribution. I had a quick
look at the file and I noticed that a very similar strings was
used instead
SSH_BUG_PKAUTH
I assumed that the first one was a typo so I replaced it with the
second one and everything went swimmingly well. Of course,
not being myself a developer or a software maintainer, I CANNOT
guarantee that the above change will leave the package unaffected.
I gave it a quick run and everything seemed to work fine.
I'll try to get in touch with the OpenSSH developers concerning this
issue.
2) I've also tried to compile a version of OpenSSH which makes use
of the prngd package also available at the above URL; from a
programmer's standpoint, it's as easy as providing the "configure"
script with the
--with-prngd-socket=<filename>
but, although the compilation went fine, I was unable to find any
evidence of its usage in the binaries so (again) I CANNOT guarantee
that the prngd version of the package actually uses it.
3) The compilation of the package under OpenUNIX8 failed due to a
SSL library "mismatch" I'm unable to resolve at the minute.
Of course, I'll be more than glad to hear from anyone who succeeded
in verifying the above points.
Last, I'm not a programmer myself not have I the required skill to
maintain the package so __PLEASE__ don't get in touch with me if you
have problems while using it.
Hope this helps !
Best,
Roberto
--
---------------------------------------------------------------------
Roberto Zini email : r.z...@strhold.it
Technical Support Manager -- Strhold Evolution Division R.E. (ITALY)
---------------------------------------------------------------------
"Has anybody around here seen an aircraft carrier?"
(Pete "Maverick" Mitchell - Top Gun)
Roberto Zini
OK, it's the end of the week and I'm very tired :-(
Everything works perfectly even with the prngd support; the fact is that
sshd does not make reference to the "egd-pool" socket file directly but
uses a file under libexec (namely "ssh-rand-helper") instead.
Sorry for that.
Roberto Zini
>
> Roberto Zini wrote:
> >
> > Hi.
> >
> > Last night I was kindly informed by Bela that a new version of
> > OpenSSH had come out so today I decided to give it a run in order
> > to provide you with some new packages to use under OpenServer5.
> >
> > The new version if 3.1p1 and is available at the following URL
> > (along with previous ones):
> >
> > ftp://ftp.strhold.it/sco_security
> >
> > I've also updated the README.ssh file so give it a read before
> > installing the software.
> >
> > A couple of notes (and PLEASE read'em carefully before downloading):
> >
> > 1) it seems that there's a typo in a 'C' module which prevents the
> > package from bein correctly compiled. In fact, in compat.c, you
> > can find a reference to
> >
I think the typo was in my mind since, by simply exploding the tarball again,
I didn't have to modify pretty anything for the configure script to work.
Again, it's friday and I'm tired ...
Also, I've just made available OpenSSH 3.1p1 for OpenUNIX8 (thanks
to Boyd Lynn Gerber for that !) at the very same URL.
I'll try to get the one for UnixWare7 early next week.
Enjoy,
Roberto
Derek Whitten
ftp://ftp.FreeBSD.org/pub/FreeBSD/CERT/advisories/FreeBSD-SA-02:13.openssh.a
sc
"Roberto Zini" <r.z...@strhold.it> wrote in message
news:3C88A57F...@strhold.it...
Matt Schalit
>Hi.
>3) The compilation of the package under OpenUNIX8 failed due to a
>SSL library "mismatch" I'm unable to resolve at the minute.
What the solution to this? I faced the same problem, which
is the reason I couldn't build OpenSSH a few weeks ago. I grepped
for the version string it was referring to and the older version
number it was finding, and I found both in the OpenSSL source code,
but couldn't figure what to do with them.
Btw, three cheers for Boyd Gerber, darnit. He does *a lot* for
Caldera OS's on his own time, behind the scenes, and I really
appreciate it.
Matthew
Boyd Lynn Gerber
> >3) The compilation of the package under OpenUNIX8 failed due to a
> >SSL library "mismatch" I'm unable to resolve at the minute.
>
>
> What the solution to this? I faced the same problem, which
> is the reason I couldn't build OpenSSH a few weeks ago. I grepped
> for the version string it was referring to and the older version
> number it was finding, and I found both in the OpenSSL source code,
> but couldn't figure what to do with them.
Same one as I have found on most Shared libraries. Add "\;" to the
LD_LIBRARY_PATH for ksh or sh. As below...
LD_LIBRARY_PATH=\;/usr/lib:/lib:/usr/local/lib:/usr/local/mysql/lib/mysql:/usr/local/bdb/lib
export LD_LIBRARY_PATH
> Btw, three cheers for Boyd Gerber, darnit. He does *a lot* for
> Caldera OS's on his own time, behind the scenes, and I really
> appreciate it.
> Matthew
Thanks,
--
Boyd Gerber <ger...@zenez.com>
ZENEZ 3748 Valley Forge Road, Magna Utah 84044
Jean-Pierre Radley
|
| Last night I was kindly informed by Bela that a new version of
| OpenSSH had come out so today I decided to give it a run in order
| to provide you with some new packages to use under OpenServer5.
|
| The new version if 3.1p1 and is available at the following URL
| (along with previous ones):
|
| ftp://ftp.strhold.it/sco_security
|
I just compiled the new version myself.
Just like the previous ones, it gives no problems at all when connecting
to various other machines, with one exception: a Linux machine running
RedHat 7.2.
On this machine, I connect, get the 'Last Login' message, and then the
shell (be it bash or tcsh) immediately core dumps on the remote so that
I never even see a shell prompt from the remote.
I've tried 'ssh -v' and can't discern anything useful:
...
jpr@remote_machine's password:
debug1: packet_send2: adding 64 (len 57 padlen 7 extra_pad 64)
debug1: ssh-userauth2 successful: method password
debug1: channel 0: new [client-session]
debug1: send channel open 0
debug1: Entering interactive session.
debug1: ssh_session2_setup: id 0
debug1: channel request 0: pty-req
debug1: channel request 0: shell
debug1: fd 3 setting TCP_NODELAY
debug1: channel 0: open confirm rwindow 0 rmax 32768
Last login: Fri Mar 8 23:02:01 2002 from jpr.com
debug1: client_input_channel_req: channel 0 rtype exit-signal reply 0
debug1: channel 0: rcvd eof
debug1: channel 0: output open -> drain
debug1: channel 0: obuf empty
debug1: channel 0: close_write
debug1: channel 0: output drain -> closed
debug1: channel 0: rcvd close
debug1: channel 0: close_read
debug1: channel 0: input open -> closed
debug1: channel 0: almost dead
debug1: channel 0: gc: notify user
debug1: channel 0: gc: user detached
debug1: channel 0: send close
debug1: channel 0: is dead
debug1: channel 0: garbage collecting
debug1: channel_free: channel 0: client-session, nchannels 1
Connection to remote_machine closed.
debug1: Transferred: stdin 0, stdout 0, stderr 36 bytes in 0.3 seconds
debug1: Bytes per second: stdin 0.0, stdout 0.0, stderr 114.4
debug1: Exit status -1
--
JP
Third
Try compiling your OpenSSH (on SCO) with PAM_TTY_KLUDGE defined. It *might*
make a difference.
-mk
Boyd Lynn Gerber
On Sat, 9 Mar 2002, Jean-Pierre Radley wrote:
> I just compiled the new version myself.
>
> Just like the previous ones, it gives no problems at all when connecting
> to various other machines, with one exception: a Linux machine running
> RedHat 7.2.
>
> On this machine, I connect, get the 'Last Login' message, and then the
> shell (be it bash or tcsh) immediately core dumps on the remote so that
> I never even see a shell prompt from the remote.
I have had the problem, but if I change TERM to ansic or ansi then I am
able to connect? For some reason scoansi core dumps.
TERM=ansic;export TERM
for sh or ksh
Good Luck,
-bill-
...
>
> OK, it's the end of the week and I'm very tired :-(
get some rest !
--
- bill -
bill at TechServSys dot com
Jean-Pierre Radley
| > to various other machines, with one exception: a Linux machine running
| > RedHat 7.2.
| >
| > On this machine, I connect, get the 'Last Login' message, and then the
| > shell (be it bash or tcsh) immediately core dumps on the remote so that
| > I never even see a shell prompt from the remote.
| >
|
| make a difference.
Boyd wrote to me off list and pointed to the problem (which I did
not have before that Linux target was running RedHat 7.1: the setting
of TERM=scoansi gets exported by ssh to the remote machine, and cause the
shell to core dump (is that normal for Linux?); setting TERM to ansi n my
machine let me get through.
--
JP
Brian K. White
I can't thank you enough for making these available Roberto.
Thanks much.
--
Brian K. White -- br...@aljex.com -- http://www.aljex.com/bkw/
+++++[>+++[>+++++>+++++++<<-]<-]>>+.>.+++++.+++++++.-.[>+<---]>++.
filePro BBx Linux SCO Prosper/FACTS AutoCAD #callahans Satriani
Matt Schalit
>Hi.
>
>Last night I was kindly informed by Bela that a new version of
>OpenSSH had come out so today I decided to give it a run in order
>to provide you with some new packages to use under OpenServer5.
>
>The new version if 3.1p1 and is available at the following URL
>(along with previous ones):
>
> ftp://ftp.strhold.it/sco_security
Apparently, Caldera has decided to get into the packaging
of OpenSSH, four days after this was posted. Nowhere in
the acknowlegements is Roberto Zini listed.
ftp://stage.caldera.com/pub/security/openserver/CSSA-2002-SCO.10/
ftp://stage.caldera.com/pub/security/openunix/CSSA-2002-SCO.11/
ftp://stage.caldera.com/pub/security/openunix/CSSA-2002-SCO.11/
More and more it looks like we do something and Caldera
copies it in one form or another. That's fine. It's their
perogative. Though Caldera may not feel like thanking us, I
appreciate what you folks have done here, including Roberto,
the regulars, and irregulars. I bet he even welcomes being
'relieved' of this duty.
Thanks ya'll,
Matthew
Bela Lubkin
> On Fri, 08 Mar 2002 12:50:23 +0100, Roberto Zini <r.z...@strhold.it> wrote:
>
> >Last night I was kindly informed by Bela that a new version of
> >OpenSSH had come out so today I decided to give it a run in order
> >to provide you with some new packages to use under OpenServer5.
> >
> >The new version if 3.1p1 and is available at the following URL
> >(along with previous ones):
> >
> > ftp://ftp.strhold.it/sco_security
>
> Apparently, Caldera has decided to get into the packaging
> of OpenSSH, four days after this was posted. Nowhere in
> the acknowlegements is Roberto Zini listed.
I can't imagine why Roberto would or should be acknowledged for anything
other than being a darn helpful guy. Building OpenSSH for any of
Caldera's OSes is not rocket science, Roberto contributed little more
than the time and effort of downloading, building and posting the
packages. The packages on Caldera's FTP site are, as far as I know,
completely unrelated to those -- someone at Caldera likewise downloaded,
built and posted them.
I was the one that notified Roberto of the problem (which, mind you, has
been widely discussed elsewhere -- neither I nor Roberto had anything to
do with either discovering or fixing the problem). I did so as a
courtesy to Roberto and to the many people who download his binaries and
would benefit from them being updated as quickly as possible.
I share your surprise at seeing Caldera suddenly get into the business
of distributing OpenSSH; we (especially the ex-SCO side of things) have
always been really scared of shipping crypto technologies, thanks to the
US government's reactionary stance.
> ftp://stage.caldera.com/pub/security/openserver/CSSA-2002-SCO.10/
> ftp://stage.caldera.com/pub/security/openunix/CSSA-2002-SCO.11/
> ftp://stage.caldera.com/pub/security/openunix/CSSA-2002-SCO.11/
>
> More and more it looks like we do something and Caldera
> copies it in one form or another. That's fine. It's their
> perogative. Though Caldera may not feel like thanking us, I
> appreciate what you folks have done here, including Roberto,
> the regulars, and irregulars.
I appreciate the work Roberto does both in answering questions here on
the newsgroups, and in providing ported software. I believe I tangibly
demonstrated that appreciation by thinking to alert him of the need to
quickly update the OpenSSH packages. But why should a separate set of
OpenSSH packages elsewhere say anything at all about him? It's as if I
told you to read "The Uplift War" because I think it's a really good
book, then a week later someone else got mad at _me _for not
acknowledging your contribution to my enjoyment of the book...?!?
> I bet he even welcomes being
> 'relieved' of this duty.
An independent entity like Roberto is likely to always be able to get
packages out more quickly than an organization like Caldera. There is a
difference of expectations and responsibilities. The packages from
Caldera have been tested in various ways (I don't know the details) and
are expected to work. I'm not saying that they always do, but there is
an expectation. I'm sure Roberto -- and any other distributor of
precompiled opensource binaries -- does some testing too, but nobody
would be surprised to find that such a package was significantly broken.
Understand that I'm not casting aspersions on Roberto or any other
builder of opensource packages, I'm just saying that there is a
different level of expectations involved. The expectation for any
commercial entity whose _business_ is providing built software includes
various sorts of testing, packaging, documentation, etc.; which takes
time to finish.
All of which amounts to: independents like Roberto, JPR, Bill Campbell
etc. will always have a useful role to play. They can, for instance,
provide emergency recuts of programs long before anyone even knows for
sure whether the proposed security fix is valid, 100% secure, sensible,
workable... and in most cases the answer will turn out to be "yes". If
not, everyone will appreciate them for having tried. If a commercial
software vendor provides that sort of ad-hoc-and-turns-out-to-be-wrong
security fix, they get roasted.
>Bela<
BDS
"Bela Lubkin" <be...@caldera.com> wrote in message
news:2002031402...@mammoth.ca.caldera.com...
<snip>> All of which amounts to: independents like Roberto, JPR, Bill
Campbell
> etc. will always have a useful role to play. They can, for instance,
> provide emergency recuts of programs long before anyone even knows for
> sure whether the proposed security fix is valid, 100% secure, sensible,
> workable... and in most cases the answer will turn out to be "yes". If
> not, everyone will appreciate them for having tried. If a commercial
> software vendor provides that sort of ad-hoc-and-turns-out-to-be-wrong
> security fix, they get roasted.
>
> >Bela<
I missed it. Has Microsoft been "roasted"?
-BDS
Jean-Pierre Radley
| An independent entity like Roberto is likely to always be able to get
| packages out more quickly than an organization like Caldera. There is a
| difference of expectations and responsibilities. The packages from
| Caldera have been tested in various ways (I don't know the details) and
| are expected to work. I'm not saying that they always do, but there is
| an expectation.
The source tarball for 3.1p1 is dated:
Mar 6 14:41 /s/src/openssh-3.1p1.tar.gz
The Caldera OSR package is dated:
Mar 12 16:38 openssh-3.1p1-VOLS.tar
Both of those are EST.
I'm truly whelmed that Caldera downloaded, compiled, tested and packaged
OpenSSH 3.1p1 in 6 days 1 hour 57 minutes !!!
I had that version compiled and bundled into a tar.bz2 archive within a
day of its appearance, only to have to redo it when a bug in zlib, which
OpenSSH uses, was fixed in zlib 1.1.4 on March 11th. I don't know if
either Caldera or Roberto incorporated the new libz into their OpenSSH
binaries yet; I've installed my tarball on several customers' machines,
and anyone is welcome to grab it:
ftp/jpr/com:/pub/opensshOSR5.tar.bz2
--
JP
scooter6
> On Sat, 9 Mar 2002, Jean-Pierre Radley wrote:
> > I just compiled the new version myself.
> >
> > Just like the previous ones, it gives no problems at all when connecting
> > to various other machines, with one exception: a Linux machine running
> > RedHat 7.2.
> >
> > On this machine, I connect, get the 'Last Login' message, and then the
> > shell (be it bash or tcsh) immediately core dumps on the remote so that
> > I never even see a shell prompt from the remote.
>
> I have had the problem, but if I change TERM to ansic or ansi then I am
> able to connect? For some reason scoansi core dumps.
>
> TERM=ansic;export TERM
>
> for sh or ksh
>
> Good Luck,
I have installed the following:
SCO OpenServer Enterprise 5.0.5
OpenSSL 0.9.6c
OpenSSH 3.0.2p1
prngd-0.9.23 (just released)
All compiling was done with gcc-2.95.2
Everything seems to compile fine....as far as doing a "sftp" I was
able to generate key, etc
Now, when I try to generate my key for OpenSSL, I get the error
stating "PRNG not seeded"
I read in the OpenSSL FAQ about that error, which states that the
"seed" file does not have 128 bits of randomness, etc, etc
Can anyone further explain this? I followed all the install
directions and it compiled and there is a "prngd-seed" file and the
prngd daemon is running.
Also, once I get this to work, I want to make sure the following is
possible:
I have a client that wants me to send a file from the SCO server to
their NT machine using the https:// protocol with cert verification,
etc
Is this possible with all of these packages installed correctly?
If so, what is the procedure to get all the "certificates" right??
Thanks for any and all assistance
Scott Ullmann
TelespectrumFX
sull...@telespectrum.com
I have tested
Matt Schalit
>Matt Schalit wrote:
>
>> On Fri, 08 Mar 2002 12:50:23 +0100, Roberto Zini <r.z...@strhold.it> wrote:
>>
>> >Last night I was kindly informed by Bela that a new version of
>> >OpenSSH had come out so today I decided to give it a run in order
>> >to provide you with some new packages to use under OpenServer5.
>> >
>> >The new version if 3.1p1 and is available at the following URL
>> >(along with previous ones):
>> >
>> > ftp://ftp.strhold.it/sco_security
>>
>> Apparently, Caldera has decided to get into the packaging
>> of OpenSSH, four days after this was posted. Nowhere in
>> the acknowlegements is Roberto Zini listed.
>
>I can't imagine why Roberto would or should be acknowledged for anything
>other than being a darn helpful guy.
[snip]
You're right. I'm wrong.
Matt
>>Bela<
Boyd Lynn Gerber
> Boyd Lynn Gerber <ger...@zenez.com> wrote in message news:<Pine.SC5.4.44.020309...@xenau105.zenez.com>...
> > On Sat, 9 Mar 2002, Jean-Pierre Radley wrote:
> > > I just compiled the new version myself.
> > >
> > > Just like the previous ones, it gives no problems at all when connecting
> > > to various other machines, with one exception: a Linux machine running
> > > RedHat 7.2.
> > >
> > > On this machine, I connect, get the 'Last Login' message, and then the
> > > shell (be it bash or tcsh) immediately core dumps on the remote so that
> > > I never even see a shell prompt from the remote.
> >
> > I have had the problem, but if I change TERM to ansic or ansi then I am
> > able to connect? For some reason scoansi core dumps.
> >
> > TERM=ansic;export TERM
To test it get egd and run the test script.
Use egc.pl to check prngd really works:
egc.pl /var/run/egd-pool get
should yield the entropy in the PRNG pool as estimated by the PRNG.
Obtain some random data for test
egc.pl /var/run/egd-pool read 255
> Now, when I try to generate my key for OpenSSL, I get the error
> stating "PRNG not seeded"
>
> I read in the OpenSSL FAQ about that error, which states that the
> "seed" file does not have 128 bits of randomness, etc, etc
>
> Can anyone further explain this? I followed all the install
> directions and it compiled and there is a "prngd-seed" file and the
> prngd daemon is running.
egc.pl allows you to test prng. I would bet openssh is looking for prng
to have it's file in /var/run/ Check your prng config. I usually have it
put the file in /var/run/egd-pool and then it works. You can go to the
prng page for help with it.
http://ftp.aet.TU-Cottbus.DE/personen/jaenicke/postfix_tls/prngd.html
Jean-Pierre Radley
| SCO OpenServer Enterprise 5.0.5
| OpenSSL 0.9.6c
| OpenSSH 3.0.2p1
| prngd-0.9.23 (just released)
|
| All compiling was done with gcc-2.95.2
|
| Everything seems to compile fine....as far as doing a "sftp" I was
| able to generate key, etc
|
| Now, when I try to generate my key for OpenSSL, I get the error
| stating "PRNG not seeded"
I do not have prng running here at all; it isn't required.
| I have a client that wants me to send a file from the SCO server to
| their NT machine using the https:// protocol with cert verification,
I don't think ssh has anything to do with https.
--
JP
Tony Lawrence
on OSR5?
I'm not the most technical geek the workd has ever seen, but I have at
least a few skills, and I find this horribly frustrating.
I installed a new 5.0.6 system and tried the Caldera Openssh link.
Great fun finding that: would it kill to DESCRIBE what these packages are?
Immediate failure of course because it needs /usr/local/lib/libz.so.1
I forgot where that came from so I figured I'd do Roberto's in case it
was in there. Of course it wasn't, and eventually I figured out that I
needed Glib from skunkware.
After that, I realized I needed prngd for Roberto's so went back and did
that. Now Roberto's works, except that it immediately disconnects and
so far ssh -v isn't helping me find out why. The Caldera still doesn't
work because it needs prngd and is looking for it somewhere else.
OK- if not all that bright, I am at least stubborn and creative- I WILL
get this working- I've had it working on other OSR5 systems so I know it
CAN work, but this is yet another example of why people get frustrated
and angry at SCO/Caldera. Skunkware does not take dependencies into
account, there's no easy way to resolve dependencies, the security site
is confusing and undocumented and incomplete, etc.
How on earth can we expect any normal human being to get throught this?
I'm frustrated and angry- how is someone with less skills, knowledge and
resources going to feel?
Roberto Zini wrote:
--
Tony Lawrence
SCO/Linux Support Tips, How-To's, Tests and more: http://pcunix.com
Jean-Pierre Radley
| How an earth is an ordinary human being ever supposed to get ssh working
| on OSR5?
|
| I'm not the most technical geek the workd has ever seen, but I have at
| least a few skills, and I find this horribly frustrating.
|
| I installed a new 5.0.6 system and tried the Caldera Openssh link.
| Great fun finding that: would it kill to DESCRIBE what these packages are?
|
| Immediate failure of course because it needs /usr/local/lib/libz.so.1
|
| I forgot where that came from so I figured I'd do Roberto's in case it
| was in there. Of course it wasn't, and eventually I figured out that I
| needed Glib from skunkware.
|
| After that, I realized I needed prngd for Roberto's so went back and did
| that. Now Roberto's works, except that it immediately disconnects and
| so far ssh -v isn't helping me find out why. The Caldera still doesn't
| work because it needs prngd and is looking for it somewhere else.
|
| OK- if not all that bright, I am at least stubborn and creative- I WILL
| get this working- I've had it working on other OSR5 systems so I know it
| CAN work, but this is yet another example of why people get frustrated
| and angry at SCO/Caldera. Skunkware does not take dependencies into
| account, there's no easy way to resolve dependencies, the security site
| is confusing and undocumented and incomplete, etc.
|
| How on earth can we expect any normal human being to get throught this?
|
| I'm frustrated and angry- how is someone with less skills, knowledge and
| resources going to feel?
Let me know if my tarball works. Prng isn't involved, and while libz is
certainly used, I built ssh with a static zlib.a instead of a dynamic
one. It's opensshOSR5.tar.bz2 at ftp.jpr.com.
--
JP
Tony Lawrence
> Tony Lawrence propounded (on Sat, Mar 16, 2002 at 01:12:50PM +0000):
> | How an earth is an ordinary human being ever supposed to get ssh working
> | on OSR5?
> |
> | I'm not the most technical geek the workd has ever seen, but I have at
> | least a few skills, and I find this horribly frustrating.
> |
> | I installed a new 5.0.6 system and tried the Caldera Openssh link.
> | Great fun finding that: would it kill to DESCRIBE what these packages are?
> |
> | Immediate failure of course because it needs /usr/local/lib/libz.so.1
>
Stuff deleted
> | I'm frustrated and angry- how is someone with less skills, knowledge and
> | resources going to feel?
>
> Let me know if my tarball works. Prng isn't involved, and while libz is
> certainly used, I built ssh with a static zlib.a instead of a dynamic
> one. It's opensshOSR5.tar.bz2 at ftp.jpr.com.
BTW, the "disconnect" problem was just the "scoansi" TERM problem- the
system I was sshing to doesn't like that. I remembered that on my way
to the gym. A simple "export TERM=ansi" fixed it.
To know if your tarball truly is self standing, I have to back out
everything I've done first. But the point isn't that you CAN build and
package programs to be independent of other packages, the point is that
SCO/Caldera Skunkware doesn't even try. Yes, I understand Skunkware is
a volunteeer effort, but I'm sure the intentions of the volunteers is
NOT to further frustrate people who came there looking to add
functionality to their system. None of us who provide freebies WANT to
frustrate anyone, and we can never completely avoid it, but we should at
least try- you don't want your efforts to end up having a negative
outcome because that doesn't help anyone.
The problem, of course, is that the typical developer already has all
kinds of stuff already installed on their system, and just doesn't take
the time to compare a ldd with what is "stock". Of course, even if they
did so, I know of no easy method on OSR5 to trace back where a
particular library could have come from.
I'd like to suggest that this is a FAQ and Skunkware project that some
of us here could contribute to: a cross reference of libraries to
packages that need them and the packages that will provide them. It
shouldn't be all that hard to do- it's just a lot of ldd'ing and
examination of Skunkware VOL's.
To that end, I added c.u.s.p and I hope that we can get a few
volunteers because it will take me forever to get it done. I would
imagine that Skunkware would happily publish this, and of course I will
too and will index it by library so folks can nail what they need quickly.
Thoughts?
Tony Lawrence
> Let me know if my tarball works. Prng isn't involved, and while libz is
> certainly used, I built ssh with a static zlib.a instead of a dynamic
> one. It's opensshOSR5.tar.bz2 at ftp.jpr.com.
>
BTW, that's yet another example of the kind of thing that frustrates
people. Somebody goes searching for OSR5 ssh binaries and gets a
pointer to your ftp site. Great! Here it is, all ready to go.. but they
can't do a thing with it because they don't have Bzip.
Now (thankfully) you *do* provide bzip on the same site, so if they
happen to notice that they will be able to enjoy success, but if they
don't- well, it's off for another net search. More frustration.
And is bzip stand alone or does it have dependencies? The cycle can go on.
And what's the point? Because bzip saves a few bytes? Because it saves
a few seconds? All to naught if they have to download it and even worse
if the non-standard compression has to send them off on yet another search.
Just my opinion, of course, but I don't think it's appropriate.
Tony Lawrence
I don't know whether this is funny or sad, but it proves my point. I
decided to see just what would happen if I had started from scratch with
JPR's openssh package.
As noted above, that package is bzipped. JPR has bzip, but.. it's not a
binary, it's the source! So now someone with a fresh OSR5 system who
only wanted ssh has to :
Go download the GNU compiler from Skunkware. That's a 24 MB download;
just the thing someone on a low speed connectionwants to do. It's made
more fun by the fact that there are multiple versions available and nary
a hint as to which one they might want.
This poor person will then learn that they also need make, so back to
Skunkware for that.
Install the Linkers and Development Libraries from their OS CD.
Compile and install bzip Assuming they have any clue at all how to do
that of course- remember they started oout looking for binaries.
But let's assume they do know enough at least to cd to the bzip
directory and run make- another surprise awaits them- make can't find ar!
Ooops. Nothing at Skunkware, nothing at JPR's site. That's probably
the end of it right here- they aren't going to get any further. But
maybe this is a personal use system so they can actually install the Dev
Sys with spending real money. Maybe. I'm really not sure what they'd
do otherwise.
Use bzip to unzip the openssh.tar package.
Untar that
Wow, ssh works.
Hardly any effort at all :-)
I ask you very seriously: is it any wonder people give up on SCO?
Tony Lawrence
> I'd like to suggest that this is a FAQ and Skunkware project that some
> of us here could contribute to: a cross reference of libraries to
> packages that need them and the packages that will provide them. It
> shouldn't be all that hard to do- it's just a lot of ldd'ing and
> examination of Skunkware VOL's.
>
> To that end, I added c.u.s.p and I hope that we can get a few
> volunteers because it will take me forever to get it done. I would
> imagine that Skunkware would happily publish this, and of course I will
> too and will index it by library so folks can nail what they need quickly.
I started with http://pcunix.com/Unicx/libxref.html and would appreciate
any and all additions and comments.
joe mc cool
> I ask you very seriously: is it any wonder people give up on SCO?
Too right.
I have largely given up - I now find Caldera Linux much easier to
install anything that is not really-really-really-really middle of the
road. Very often the grind just isn't worth the bother.
--
Joe Mc Cool C.Eng, SMIEEE
========================================================================
Tangent Computer Research BT71 7LN (www.tangent-research.com)
voice:(44)2837-548074fax:(44)-870-0520185 The more you say the less the better.
Jean-Pierre Radley
| Jean-Pierre Radley wrote:
|
|
| >Let me know if my tarball works. Prng isn't involved, and while libz is
| >certainly used, I built ssh with a static zlib.a instead of a dynamic
| >one. It's opensshOSR5.tar.bz2 at ftp.jpr.com.
|
|
| BTW, that's yet another example of the kind of thing that frustrates
| people. Somebody goes searching for OSR5 ssh binaries and gets a
| pointer to your ftp site. Great! Here it is, all ready to go.. but they
| can't do a thing with it because they don't have Bzip.
|
| Now (thankfully) you *do* provide bzip on the same site, so if they
| happen to notice that they will be able to enjoy success, but if they
| don't- well, it's off for another net search. More frustration.
|
| And is bzip stand alone or does it have dependencies? The cycle can go on.
Well, as you;ve since found out, my ftp site provides source code; the
opensshOSR5 is a rare exception.
| And what's the point? Because bzip saves a few bytes? Because it saves
| a few seconds? All to naught if they have to download it and even worse
| if the non-standard compression has to send them off on yet another search.
Well, yeah, the .bz2 file is 16% smaller than the .gz file, and I did
want to move this to several customers' computers which don't always
have very fast connections. On all of those customer sites I long ago
copied in the contents of the "jprstuff" CD which I frequently recut,
which installs bzip2, along with less, lynx, tcsh, u386mon, smail,
Taylor-uucp, xc, xt, lsof, netcat, ncftp, mutt, prune, mawk, par, and
several other utilities.
But your point is well taken. I've now replaced opensshOSR5.tar.bz2
with opensshOSR5.tgz on my ftp site.
--
JP
Tony Lawrence
So they have to go get gzip now instead :-)
Jean-Pierre Radley
Aw, let 'em eat cake (while they fetch gzipx.taz from my site). :-)
--
JP
Bill Vermillion
Jean-Pierre Radley <j...@jpr.com> wrote:
>Tony Lawrence propounded (on Sat, Mar 16, 2002 at 05:12:04PM +0000):
>| Jean-Pierre Radley wrote:
>| >Let me know if my tarball works. Prng isn't involved, and while
>| >libz is certainly used, I built ssh with a static zlib.a instead
>| >of a dynamic one. It's opensshOSR5.tar.bz2 at ftp.jpr.com.
>| BTW, that's yet another example of the kind of thing that
>| frustrates people. Somebody goes searching for OSR5 ssh binaries
>| and gets a pointer to your ftp site. Great! Here it is, all ready
>| to go.. but they can't do a thing with it because they don't have
>| Bzip.
>| Now (thankfully) you *do* provide bzip on the same site, so if
>| they happen to notice that they will be able to enjoy success,
>| but if they don't- well, it's off for another net search. More
>| frustration.
....
>| And what's the point? Because bzip saves a few bytes? Because it
>| saves a few seconds? All to naught if they have to download it
>| and even worse if the non-standard compression has to send them
>| off on yet another search.
>Well, yeah, the .bz2 file is 16% smaller than the .gz file, and I
>did want to move this to several customers' computers which don't
>always have very fast connections. ...
>But your point is well taken. I've now replaced opensshOSR5.tar.bz2
>with opensshOSR5.tgz on my ftp site.
But new compression ideas keep coming along.
From a month or so ago. The URL may be stale by now. Edited to
some of the highlights.
--------------------------------------------------------------
This story was printed from ZDNN,
located at http://www.zdnet.com/zdnn.
--------------------------------------------------------------
Researchers squeeze storage breakthrough
By Reuters
January 8, 2002 5:20 AM PT
URL:
http://www.zdnet.com/zdnn/stories/news/0,4586,2837117,00.html?chkpt=zd
nnp1tp02
NEW YORK--A Florida research start-up working with a team
of renowned mathematicians said on Monday it had achieved a
breakthrough that overcomes the previously known limits of
compression used to store and transmit data.
If proven and successfully commercialized, the discovery asserted
by ZeoSync of West Palm Beach, Florida could overturn half a
century of thinking in the field of lossless data compression and
undermine business assumptions on which the telecommunications
and other digital industries are based.
....
ZeoSync said its scientific team had succeeded on a small scale
in compressing random information sequences in such a way as
to allow the same data to be compressed more than 100 times
over--with no data loss. That would be at least an order of
magnitude beyond current known algorithms for compacting data.
The company's claims, which are yet to be demonstrated in any public
forum, could vastly boost the ability of computer disks to store,
text, music and video--if ZeoSync's formulae succeed in scaling up to
handle massive amounts of data.
The same compression technique might one day make make high-speed
Internet access cheaper and widely available across the globe, posing
a threat to huge investments in telecommunications network capacity,
an industry analyst said.
"Either this research is the next 'Cold Fusion' scam that dies
away or it's the foundation for a Nobel Prize. I don't have an
answer to which one it is yet," said David Hill, a data storage
analyst with Boston-based Aberdeen Group.
....
ZeoSync, whose Web site can be located at
http://www.zeosync.com/, was founded by Peter St. George,
an Internet and financial services entrepreneur, who has a
background in telecommunications research.
....
Among the scientific team working with ZeoSync is Steve Smale,
one of America's most renowned mathematicians. Smale is an
emeritus professor at the University of California at Berkeley
and the 1966 winner of the Fields Prize, the Nobel Prize for
researchers in this field. He could not be reached for comment on
his role in the project.
Peter St. George, ZeoSync founder and chief executive, said
his company's technique challenged the foundations of digital
communications theory spelled out by AT&T's Dr. Claude Shannon in
his classic 1948 treatise on Information Theory.
...
"What we've developed is a new plateau in communications theory," St.
George said. "We are expecting to produce the enormous capacity of
analog signaling, with the benefit of the noise-free integrity of
digital communications."
....
Rest deleted - wjv
There is always something new happening somewhere. Note above the
comment on this could be another 'cold fusion'. We will have to
wait and see if it works or is just smoke and mirrors.
Bill
--
Bill Vermillion - bv @ wjv . com
Tony Lawrence
But that goes back to my original point. I assume that, like me, you
put stuff out for both your own needs and to be helpful to the community
at large. If your intention is to be helpful, one wouldn't think that
you would want to frustrate any member of that community by forcing them
into multiple steps.
And,again, your gzip is source- our hypothetical person was here looking
for binaries. More frustration.
Of course it is isn't your responsibility to handhold anyone. You've
provided a nicely packaged openssh that (unlike the one at Caldera's
security site) actually works without further effort. That in itself
will cause many folks to be quite grateful.
The phrase "why do it half way?" comes to mind, but it isn't half way-
it's much more than that; it's just that tiny extra step. If you are
going to provide binaries at all, why not give them a normal .Z version
in addition to whatever bzip2/ultrazip8 packaging you currently prefer?
*Entirely* my opinion, of course.
Jean-Pierre Radley
|
| And,again, your gzip is source- our hypothetical person was here looking
| for binaries. More frustration.
Look again, Tony.
In the pub directory on ftp.jpr.com, there are:
-r--r----- 1 root 328945 Aug 3 2001 gzip-1.2.4a.tar.Z
-r--r----- 1 root 82975 Aug 3 2001 gzipx.tar.Z
The first is source code; the second is banaries.
| Of course it is isn't your responsibility to handhold anyone. You've
| provided a nicely packaged openssh that (unlike the one at Caldera's
| security site) actually works without further effort. That in itself
| will cause many folks to be quite grateful.
|
| The phrase "why do it half way?" comes to mind, but it isn't half way-
| it's much more than that; it's just that tiny extra step. If you are
| going to provide binaries at all, why not give them a normal .Z version
| in addition to whatever bzip2/ultrazip8 packaging you currently prefer?
|
| *Entirely* my opinion, of course.
I assume that folks might want to get more than one item from my ftp
site, and gzip isn't just a "use-it-once" tool, folks will find plenty of
opporunities to use it.
Meanwhile, feel free to change the package into a 'compress -H' version
and put it next to Roberto's on pcunix.com.
--
JP
Bill Vermillion
And gzip is so ubitquitos that's its almost strange that Caldera
doesn't include it in the current version. I'd venture that OS5 is
one of the few OSes where it is not shipped as standard. At least
thats the view from my distorted corner of the world.
Jean-Pierre Radley
|
| And gzip is so ubitquitos that's its almost strange that Caldera
| doesn't include it in the current version. I'd venture that OS5 is
| one of the few OSes where it is not shipped as standard. At least
| thats the view from my distorted corner of the world.
Gzip will be part of the next release of OSR 5.
--
JP
Tony Lawrence
'bout time.
Brian K. White
> Jean-Pierre Radley wrote:
>
>
> > Let me know if my tarball works. Prng isn't involved, and while libz is
> > certainly used, I built ssh with a static zlib.a instead of a dynamic
> > one. It's opensshOSR5.tar.bz2 at ftp.jpr.com.
> >
>
>
> BTW, that's yet another example of the kind of thing that frustrates
> people. Somebody goes searching for OSR5 ssh binaries and gets a
> pointer to your ftp site. Great! Here it is, all ready to go.. but they
> can't do a thing with it because they don't have Bzip.
- forward: This is not personally directed at you Tony, I'm just
putting forth an emphatically different point of view on this topic. -
oh wahhh :)
I have no patience for people who think the guy doing the real work is
obligated to also practically install and configure it on their
machine for them too.
I can *kind* of see how one might look at it like someone fixing your
car, that is the real work that you really needed and would be strung
without, but leaving greasy hand prints all over the hood and handles
and steering wheel. yeah it's not nice, but if there were only 10
automechanics in the world, and one of them decided to fix your car
for free after you had beat your head for a year trying and failing to
do it yourself, or were simply too lazy to even take a look at doing
it yourself, and he does it, and the car runs like a top, and you said
"man mechanics sure suck when they do that, leaving figerprints all
over..."
bzip compresses between 10 to 20 percent further than gzip, granted,
that borders on unimportant difference, but gzip compresses about 100%
better than the stock compress, not so much better than compress -H,
but then the -H is not 100% compatible either is it? so, the real
important choice could be boiled down to "make it 100% compatible" or
don't worry. If you commit to being fully compatible then you use
plain sco tar and plain sco compress with no -H option and you live
with a very large xxx.tar.Z, if that file is too large, or the
difference between that and what could be had by using anything else
is too great for your basic technicians sense of right and wrong vis a
vis efficiency, then you might as well use bzip2 as any other thing.
it's no worse than gzip in this respect since neither comes
pre-installed on sco, and both are exactly as easy to install and use
as the other (both can be simply copied the single bzip2 binary, and
both are also available on the skunkware CD and ftp site for nice
package-manager style install via custom)
The difference in size is probably unimportant to any single file even
comparing the two extreme cases, but if have more than one file to
transfer or store in your life, even that 10% is a big deal.
finally.... who installs ssh on sco boxes anyway? people who need or
expect to keep using their system in it's stock installed state? no,
those people are using telnet and rlogin. if you are replacing telnet
with ssh, then I say it is not unreasonable to expect you to at least
be comfortable with also replacing compress with bzip2. Otherwise, you
are hardly fit to be installing and configuring ssh in the first
place, *especially* on sco which is not one of the environments it is
most commonly used on, developed on, and thus, supported on.
Roberto Zini
>
> Matt Schalit wrote:
>
> > On Fri, 08 Mar 2002 12:50:23 +0100, Roberto Zini <r.z...@strhold.it> wrote:
> >
> > >Last night I was kindly informed by Bela that a new version of
> > >OpenSSH had come out so today I decided to give it a run in order
> > >to provide you with some new packages to use under OpenServer5.
> > >
> > >The new version if 3.1p1 and is available at the following URL
> > >(along with previous ones):
> > >
> > > ftp://ftp.strhold.it/sco_security
> >
> > Apparently, Caldera has decided to get into the packaging
> > of OpenSSH, four days after this was posted. Nowhere in
> > the acknowlegements is Roberto Zini listed.
>
> I can't imagine why Roberto would or should be acknowledged for anything
> other than being a darn helpful guy. Building OpenSSH for any of
> Caldera's OSes is not rocket science,
Quite correct
> Roberto contributed little more
> than the time and effort of downloading, building and posting the
> packages. The packages on Caldera's FTP site are, as far as I know,
> completely unrelated to those -- someone at Caldera likewise downloaded,
> built and posted them.
That's exactly what I did; it's only a matter of getting the right libs
in their right place and provide the "configure" script with a couple
of command-line parameters as to set the right installation directory.
>
> I was the one that notified Roberto of the problem (which, mind you, has
> been widely discussed elsewhere -- neither I nor Roberto had anything to
> do with either discovering or fixing the problem). I did so as a
> courtesy to Roberto and to the many people who download his binaries and
> would benefit from them being updated as quickly as possible.
[Bela's good points snipped]
Bela's point are quite on the track; I mean, my only aim was to give people
an (hopefully) read-to-go OpenSSH package they could use in their own
environment. That's all; I'm not going either to enhance it or to support
it mainly 'cause I don't have the required skills to do the job.
Also, I'm sort of excited to hear that Caldera's entered the OpenSSH distibution
since this should guarantee a certain level of testing & packaging (things
that I've only tested a little bit and so cannot guarantee the effectiveness
of the package) and a "fixed point" from which you can obtain the software.
Best,
Roberto
--
---------------------------------------------------------------------
Roberto Zini email : r.z...@strhold.it
Technical Support Manager -- Strhold Evolution Division R.E. (ITALY)
---------------------------------------------------------------------
"Has anybody around here seen an aircraft carrier?"
(Pete "Maverick" Mitchell - Top Gun)
Tony Lawrence
> Tony Lawrence <to...@pcunix.com> wrote in message news:<3C937DA5...@pcunix.com>...
>>
>>BTW, that's yet another example of the kind of thing that frustrates
>>people. Somebody goes searching for OSR5 ssh binaries and gets a
>>pointer to your ftp site. Great! Here it is, all ready to go.. but they
>>can't do a thing with it because they don't have Bzip.
>>
>
> - forward: This is not personally directed at you Tony, I'm just
> putting forth an emphatically different point of view on this topic. -
>
> oh wahhh :)
>
> I have no patience for people who think the guy doing the real work is
> obligated to also practically install and configure it on their
> machine for them too.
Not the point.
As someone providing a service to someone else, you aren't OBLIGATED
to do anything,and the operating phrase is "you don't look a gift horse
in the mouth".
However: obviously you have REASONS for sharing whatever it is you
shared. Sometimes those reasons are completely altruistic, but more
commonly there is some self-directed motivation that is at least part of
it: you perhaps hope to gain some degree of award, financial, fame,
whatever.
In the case of sharing binaries like this, your altruistic motives might
include easing the pain of Unix for those new to it, and your other
motives might include being seen as a person who can do such things,
which might bring you income later, recognition from your peers now, etc.
Given that you have at least one or more of those motives, why on earth
would you want to screw it up by making it difficult?
You say:
> finally.... who installs ssh on sco boxes anyway? people who need or
> expect to keep using their system in it's stock installed state? no,
> those people are using telnet and rlogin. if you are replacing telnet
> with ssh, then I say it is not unreasonable to expect you to at least
> be comfortable with also replacing compress with bzip2. Otherwise, you
> are hardly fit to be installing and configuring ssh in the first
> place, *especially* on sco which is not one of the environments it is
> most commonly used on, developed on, and thus, supported on.
Someone might very well want ssh JUST so they can ssh out to somewhere
else. That's what I use it for on the SCO box here- I have no need to
run sshd, but when I'm doing SCO work it is convenient to be able to use
ssh to go out. There's no configuration, so it's not a case where
anyone needs to know anything more than getting the ssh binary.
So-again- why make it difficult? If your motives were to ease the pain of Unix,
you sure haven't helped that at all. If you wanted recognition, well, you probably
got that, but you also probably got annoyance along with it, and
annoyance tends to cancel out the recognition, doesn't it?
IMHO, this has been one of the many problems that have kept Unix pushed
down: this geek mentaility that demands a test of manhood in exchange
for anything it gives freely.
Tony Lawrence
Except I'm not sure they really have. Their version requires prng and
they did not provide that (or if they did it's burried in that stupid
maze of meaningless numbers).
Robert Carnegie
> in compressing random information sequences in such a way as
> to allow the same data to be compressed more than 100 times
> over--with no data loss. That would be at least an order of
> magnitude beyond current known algorithms for compacting data.
>
> The company's claims, which are yet to be demonstrated in any public
> forum, could vastly boost the ability of computer disks to store,
> text, music and video--if ZeoSync's formulae succeed in scaling up to
> handle massive amounts of data.
>
> smoke and mirrors.
Not to take away from your point that technology advances, including
in compression, but I'd say wait no more on this one:
http://zdnet.com.com/2100-1104-839884.html ,
and comp.compression's http://www.faqs.org/faqs/compression-faq/ .
www.zeosync.com claims no "news" since 2002-01-21, which is not
always a bad sign, but is not good for a company with a new product
running on "Internet time".
When anyone claims to have reliable compression of an unbiased
random data stream, without data loss, you know that they don't.
Reuters may not be hip to this, though ;-)
Suppose that the compressor reliably reduces every possible random
data pattern of n bits by one bit - that's 2^n different inputs -
then there must be 2^n different outputs, each of which gives you
back one of the 2^n different inputs when you run the decompressor.
But the outputs are all bit strings of length n-1, and so there can
only be 2^(n-1) different outputs. Therefore there are only 2^(n-1)
outputs from the decompressor.
Technology advances, but maths doesn't change. And if something
sounds way too good to be true then it probably is.
You know that we'd have to wait forever for a version that runs
on platforms other than Microsoft Windows, anyway :-)
The FAQ includes an entertaining account of the actual "smoke and
mirrors" often - yes, often - used by software to pretend to be
compressing data. I'll suggest an easy one for UNIX which someone
could script up by April 1st: move the real data file to /tmp/ with
a less visible dot-filename, and store the inode number for the
file in the so-called "compressed" file. The "decompressor" reads
the 2 or 4 byte number from the "compressed" file and "uncompresses"
your file. Some random padding can be added to the "compressed" file
if you anticipate that victims won't believe that absolutely any
data - the magazine-length memo that they spent hours typing, for
instance - can be reduced to 4 bytes.
Of course, hiding the data elsewhere on the local disk doesn't work
when a user tries to copy and "uncompress" the file on another host.
On the other hand, these days you can probably hide it out on the
Internet. If users don't notice the dialer starting up unexpectedly -
Bill Vermillion
Robert Carnegie <rja.ca...@excite.com> wrote:
>b...@wjv.comREMOVE (Bill Vermillion) wrote in message news:<Gt3so...@wjv.com>...
>>
>> From a month or so ago. The URL may be stale by now. Edited to
>> some of the highlights.
>> --------------------------------------------------------------
>> This story was printed from ZDNN,
>> located at http://www.zdnet.com/zdnn.
>> --------------------------------------------------------------
>>
>> Researchers squeeze storage breakthrough
>> By Reuters
>> January 8, 2002 5:20 AM PT
>> URL:
>> http://www.zdnet.com/zdnn/stories/news/0,4586,2837117,00.html?chkpt=zd
>> nnp1tp02
[excess posting material deleted - wjv]
>> We will have to wait and see if it works or is just
>> smoke and mirrors.
>Not to take away from your point that technology advances, including
>in compression, but I'd say wait no more on this one:
>http://zdnet.com.com/2100-1104-839884.html ,
>and comp.compression's http://www.faqs.org/faqs/compression-faq/ .
>www.zeosync.com claims no "news" since 2002-01-21, which is not
>always a bad sign, but is not good for a company with a new product
>running on "Internet time".
If you read the original story [I edited it for imporant points]
they expected to have commercial product in 2003. Nothing said 60
days after announcment would not be considered to be worrisome for
a product that is not due out for perhaps 400 days. They also said
"details would be announced in the coming months".
>When anyone claims to have reliable compression of an unbiased
>random data stream, without data loss, you know that they don't.
>Reuters may not be hip to this, though ;-)
I never dismiss anything off hand until I see more information.
So many things that just "couldn't be done" a few years ago are
done on routine basis.
The Aberdeen group researcher who was briefed on this basically
said it is another "cold fusion" or the basis for a Nobel Prize.
I must admit that since I'm not a mathematican the description
that it "intentionally randomizes naturally occuring patterns to
form entropy-like random sequences" doesn't describe it in terms I
readily understand.
Disk density was thought to be nearing it's limit because of
the paramagnetic limitations - but IBM took some new approaches
and it looks like what was thought to be the limit will now be
about 4-6 times the previous one. IOW we could see .5 TB drives in
about 2 years.
Optical data transmission was thought to be limited to about
2Tb/second. IBM figures it will now work at about 100Tb/second
using 'techniques from quantum physics and information theory'
That doesn't include the announcement from Corning in January where
they said they had developed newer glass fibers that would also
increase the limit.
In this field there are few things that are up against a
stone-wall. While the original comment did did say that
it could turn out to be like 'cold-fusion' the side effect of that
was that the lower limits in that field have been raised by about
100 degrees. It's easier to lower something to about -360F than it
is -460F.
>Technology advances, but maths doesn't change. And if something
>sounds way too good to be true then it probably is.
I'll let you and Steve Smale argue the math side. The article
indicated he was "one of America's most reknowned mathemeticians".
>You know that we'd have to wait forever for a version that runs
>on platforms other than Microsoft Windows, anyway :-)
That's not the target. Digital broadcast video standard for normal
video - not hidef - are around 14MBytes/second. If it the new
compression scheme works it could replace the MPEG standards so
that you could either transmit more content on a given bandwidth or
higher quality.
I'm content to wait and see and not try to second guess.
Roberto Zini
>
> Bela Lubkin propounded (on Thu, Mar 14, 2002 at 10:20:00AM +0000):
> | An independent entity like Roberto is likely to always be able to get
> | packages out more quickly than an organization like Caldera. There is a
> | difference of expectations and responsibilities. The packages from
> | Caldera have been tested in various ways (I don't know the details) and
> | are expected to work. I'm not saying that they always do, but there is
> | an expectation.
>
> The source tarball for 3.1p1 is dated:
> Mar 6 14:41 /s/src/openssh-3.1p1.tar.gz
> The Caldera OSR package is dated:
> Mar 12 16:38 openssh-3.1p1-VOLS.tar
>
> Both of those are EST.
>
> I'm truly whelmed that Caldera downloaded, compiled, tested and packaged
> OpenSSH 3.1p1 in 6 days 1 hour 57 minutes !!!
>
> I had that version compiled and bundled into a tar.bz2 archive within a
> day of its appearance, only to have to redo it when a bug in zlib, which
> OpenSSH uses, was fixed in zlib 1.1.4 on March 11th. I don't know if
> either Caldera or Roberto incorporated the new libz into their OpenSSH
> binaries yet ...
[snip]
Well, I didn't include the new zlib package but a quick check with ldd
reveals that the version of ssh I've made available does use
/usr/local/lib/libz.so.1
Being a shared library, the user is free to download/build/install the
zlib package he/she likes best.
Greg M Lee
You are having a bad day Tony !!
I too get frustrated by the lack of documentation of dependencies, but
they usually aren't that hard to find:
ftp://ftp2.caldera.com/pub/skunkware/osr5/bin/gunzip
ftp://ftp2.caldera.com/pub/skunkware/osr5/bin/gzcat
ftp://ftp2.caldera.com/pub/skunkware/osr5/shellutil/bzip2/bzip2-0.9.5d-dist.tar.gz
ftp://ftp2.caldera.com/pub/skunkware/osr5/sysadmin/prngd/prngd-0.9.6-dist.tar.gz
Linux RPM isn't all that great either when you have a situation like:
the
only pre-compiled version of a program you want uses an older version of
libraries from two packages that rpm won't let you install or if you
force
the rpm install breaks dozens of other programs, so you try to compile
it
from source but find you need the older version of the compiler, and
on it goes !
Just my $0.02
-Greg
PS It really is a lovely sunny day outside my office so it is hard to
stay
grouchy for long.
Stuart J. Browne
news:3C969971...@ncs.co.nz...
.. naw, it's easy! 'cause I'm stuck inside and can't get to that lovely
outside!
But then again, I'm a pessimistic grouch :)
bkx
Brian K. White
hehhe ! exactly. I'm pleased to see you understand, agreement is less
necessary than accurate assessment. :)
Your other points do in fact make perfect sence to me. And I don't
even wholly disagree with them. You are simply asking a valid question
based on a collection of observed behaviours that I grant you, do not
seem fully practical.
My own take is not necessarily that I think it's actually better this
way for any particular reason (doing the real work and leaving it up
to the user to know what to do with a .tgz file for example), simply
that I very much dislike being directed out of turn (not my employer,
not a legaly superior authority, not someone I have chosen to defer to
out of respect they have earned from me, etc...), so in turn, I have
very little inclination to tell someone else what to do without real
necessity. and this percolates down and has it's effect on all other
little minute by minute passing thoughts and attitudes, such that in a
situation like this where if I even have any thought about the way
someone chose to package their package, my only guidline is if the
necessary tools are reasonably discernable and reasonably obtainable,
given the target audience.
now the definitintion of "the target audience" is probably the source
of the biggest measure of the difference between your position and
mine.
You seem to be willing to include a lot of people in that group that I
just wouldn't. If you don't know what to do with a something.tar.bz2,
then you shouldn't be messing with the system. If you are simply a
beginner (no crime in that), then assuming that you are not futzing
with a production machine, simply caome back here and say "ok I'm a
beginner trying to get familiar with unix, and I don't know what to do
with this file"
They will promptly be directed to your newtosco page and similar
stuff.
so they learn the basics, only *then* should they try to perform any
of the more involved things (well, go ahead and try by all means,
that's the only way to learn, just don't expect things to just work
the first time without having to have much idea what's all going on)
Otherwise, people who shouldn't be touching stuff come in here and
email us directly for in depth help that they don't even realize *is*
in-depth. They don't realise how *many* different things *might* be
the cause of their problem and it all depends on so *many* other
things... sometime I see a question and I don't even know where to
begin formulating an answer exept for the (agreed, not nice): "go play
with unix for a few months, then come back and ask that, or just hire
me (or anyone) to take care of it, but don't expect me (or anyone) to
put the kind of time in for free that *that* question would require."
I know this is the reason I have simply not commented at all to a
running steady small percentage of posts here.
And probably most of the ...strictness of this attitude at least on my
part comes beleive it or not, from my knowledge of of just how
pathetically *little* I actually know. I guess the rationale is, heck
if I, who considers himself during certain phases of the moon to be
barely qualified to do the most basic sysadmining, and and xxx
question is stunningly obvious to me, then the asker must really
really really not be helped along his way to learning how to restore
from the tapes he's probably not making...
Like if a guy is going to repair a TV, and then has to ask someone
which type of screwdriver is needed to get the back off.
maybe it is a test of manhood, but maybe it's a perfectly reasonable
one.
Bill Vermillion
Brian K. White <br...@aljex.com> wrote:
>> ... this geek mentaility that demands a test of manhood in exchange
>> for anything it gives freely.
[Was it Tony who said that? - Missing attribution.]
>... simply
>that I very much dislike being directed out of turn (not my employer,
>not a legaly superior authority, not someone I have chosen to defer to
>out of respect they have earned from me, etc...), so in turn, I have
>very little inclination to tell someone else what to do without real
>necessity. and this percolates down and has it's effect on all other
>little minute by minute passing thoughts and attitudes, such that in a
>situation like this where if I even have any thought about the way
>someone chose to package their package, my only guidline is if the
>necessary tools are reasonably discernable and reasonably obtainable,
>given the target audience.
That is somewhat counter to the traditional Usenet helpfulness.
Traditionally people ask for help and someone offers it. The side
effect is that others who had not asked also get useful information.
That's the traditional sharing - and it's also the 'pay forward'
model - brought into the mainstream by the recent film "Pay It
Forward".
>You seem to be willing to include a lot of people in that group
>that I just wouldn't. If you don't know what to do with a
>something.tar.bz2, then you shouldn't be messing with the system.
>If you are simply a beginner (no crime in that), then assuming that
>you are not futzing with a production machine, simply caome back
>here and say "ok I'm a beginner trying to get familiar with unix,
>and I don't know what to do with this file"
That attitude is quite common [from my observation] in the Linux
NG's. Those seem to be the most confrontational [of the
technical groups] so that if you ask a question at a low level you
will sometimes be greeted by a string of four letter words, made to
think you life is worthless and should never be let near a computer
- ever.
>so they learn the basics, only *then* should they try to perform
>any of the more involved things (well, go ahead and try by all
>means, that's the only way to learn, just don't expect things to
>just work the first time without having to have much idea what's
>all going on)
And just where do they go to learn except the groups here.
If you use SCO [any so many people still call it that even though
the name has changed] this NG - .misc - makes sense while the
programmers might not. When you are learning you don't know
enough to know what you can or can not do. Someone points to a
file somewhere that will fulfill a function needed - and they don't
know how to handle it. If they don't have any one to ask where
else but here?
>Otherwise, people who shouldn't be touching stuff come in here and
>email us directly for in depth help that they don't even realize
>*is* in-depth.
Correct. They don't know enough to know that they don't know.
But direct email can be 1) ignored or 2) tell them you charge
for email support.
>They don't realise how *many* different things *might* be the cause
>of their problem and it all depends on so *many* other things...
As Tony pointed out with his problems you don't really know what is
needed as a dependency. So many OSes seem to miss this important
step - if you install something it should check for dependencies
and offer you options to get them and continue, stop the install
before you go further, or perhaps some other option.
The SGI IRIX installs had about the best checking of anything I'd
used up until then. If it needed a library and it was not already
installed on the system it would prompt you, so you could then get
another CD from the set, or ask how to handle it.
The installs which depend on other files not included in the
packages are still one of the biggest stumbling blocks for a
great many users. This is typical of so many *n*x systems. I like
the method that checks for dependencies and if they aren't there
automatically goes to the 'net and gets them.
>sometime I see a question and I don't even know where to begin
>formulating an answer exept for the (agreed, not nice): "go play
>with unix for a few months, then come back and ask that,
And that is almost a typical comment I see in the Linux groups.
While some many complain of the brusqueness of some of the posters,
and I've had few barbs hurled my way for things someone did not
consider helpful, the SCO group really are quite helpful and
non-confrontational when compared with others.
>or just hire me (or anyone) to take care of it, but don't
>expect me (or anyone) to put the kind of time in for free that
>*that* question would require."
Not free in email. But free in the NG >if< you feel like you want
to tackle it. Many years ago I posted a rather complex process on
a tech oriented group [it was over 30K and I try not to get that
long anymore] and someone wrote back and wanted to reprint it - and
I polished up and it was published. Sometimes helping someone
comes back in ways you don't imagine at first.
>I know this is the reason I have simply not commented at all to a
>running steady small percentage of posts here.
If you can't add something substantive then just don't bother to
comment at all.
>And probably most of the ...strictness of this attitude at least
>on my part comes beleive it or not, from my knowledge of of just
>how pathetically *little* I actually know. I guess the rationale
>is, heck if I, who considers himself during certain phases of the
>moon to be barely qualified to do the most basic sysadmining, and
>and xxx question is stunningly obvious to me, then the asker must
>really really really not be helped along his way to learning how to
>restore from the tapes he's probably not making...
In this ever-exploding field we have to rely on the synergy of our
fellow posters as this is so *much* to know and I've never met
anyone who was a complete expert in any field. [You could take that
in two ways - with one of them being I need to get to know a better
class of experts :-)]
>Like if a guy is going to repair a TV, and then has to ask someone
>which type of screwdriver is needed to get the back off.
They always pick the wrong one. And I used to have problems with
one tech who always used the Reed-Prince screwdriver for all the
small Phillips screws. It's sharp point fit in a great many Phillips
screws - so he didn't have to worry about picking the correct one -
but this was at the expense of ruining the Reed-Prince. Like trying
to use a regular on a Torx [sp?] head.
>maybe it is a test of manhood, but maybe it's a perfectly
>reasonable one.
Is it?
Steve Fabac
>
> Apparently, Caldera has decided to get into the packaging
> of OpenSSH, four days after this was posted. Nowhere in
> the acknowlegements is Roberto Zini listed.
>
> ftp://stage.caldera.com/pub/security/openserver/CSSA-2002-SCO.10/
> ftp://stage.caldera.com/pub/security/openunix/CSSA-2002-SCO.11/
> ftp://stage.caldera.com/pub/security/openunix/CSSA-2002-SCO.11/
>
I downloaded oenssh-3.1p1-vols.tar from the above link, read the
cssa-2002-sco.10.txt file and downloaded prngd zlib as directed:
ftp://ftp2.caldera.com/pub/skunkware/osr5/vols/zlib-1.1.4-VOLS.tar
ftp://ftp2.caldera.com/pub/skunkware/osr5/vols/prngd-0.9.23.VOLS.tar
and installed them on an SCO 5.0.5 system without problem.
I e-mailed the files as as attachments to a client and talked him
through the steps to install all the files on an Openserver 5.0.4 system
patched with rs504c, and oss601a.
The steps were to use custom to install zlib and prngd, exit custom
and run /etc/init.d/pringd enable and then /etc/init.d/pringd start.
The next step was to run custom and install Openssh-3.1p1-fols.tar
then run /etc/init.d/sshrc enable and /etc/init.d/sshrc start.
The problem occurred on the sshrc start command: it exited with the
following error message
dynamic linker: /usr/local/sbin/sshd: symbol not found: daemon
sshrc: 7179 Killed
Can anyone tell from the above message what is missing?
--
Steve Fabac
S.M. Fabac & Associates
816/765-1670
Boyd Lynn Gerber
I found that I had to add this to my S99sshd file to get them to work.
LD_LIBRARY_PATH=\;/usr/lib:/lib:/usr/local/lib:/usr/local/mysql/lib/mysql:/usr/local/bdb/lib
export LD_LIBRARY_PATH
Good Luck,
--
Boyd Gerber <ger...@zenez.com>
ZENEZ 3748 Valley Forge Road, Magna Utah 84044
Ron Record
I've uploaded an sshd binary compiled for OpenServer which has the
daemon.o from libsocket.a linked statically. This should work for
OpenServer 5.0.4 but i haven't tested it yet. OpenServer 5.0.4 is
no longer supported and i don't test Skunkware packages on that release.
I'd suggest upgrading even tho i'm fond of running old releases myself.
Anyway, i'd be interested to know if it works. You can download the binary at:
ftp://ftp2.caldera.com/pub/skunkware/osr5/shells/sshd-pre-5.0.5
-rr-
Steve Fabac
Ron,
I'll down load it and give it a try. Here is some more information
on the problem with the current version and problems I found on my
OS 5.0.5 system after my first post:
I was on-site with the client Tuesday morning and I tried to resolve the
problem but had no luck. The sshd would not start and gave the indicated
error message. When I tried starting up sshrc manually, I kept getting
the error "ksh: /etc/rc2.d/S92sshrc not found" Even though the symlink
existed and pointed to /etc/init.d/sshrc. You could vi
/etc/rc2.d/S82sshrc and get the file. I traced the problem to the
first line of sshrc that reads: #!/sbin/sh. /sbin doesn't exist on
5.0.4.
When I changed the line to #!/bin/sh, I could then type
/etc/rc2.d/S98sshrc and it would start up but then fail with the
message:
> > dynamic linker: /usr/local/sbin/sshd: symbol not found: daemon
> > sshrc: 7179 Killed
I then tried to ssh as a normal user to another client's system and
received the following error:
> OpenSSH_3.1p1, SSH protocols 1.5/2.0, OpenSSL 0x0090603f
> debug1: Reading configuration data /usr/local/etc/ssh_config
> debug3: Seeing PRNG from /usr/local/libexec/ssh-rand-helper
> debug1: Rhosts Authentication disabled, originating port will not be trusted.
> debug1: restore_uid
> debug1: ssh_connect: getuid 347 geteuid 347 anon 1
> debug1: Connecting to ############## [##.##.##.193] port 22.
The above obscured intentionally.
> debug1: temporarily_use_uid: 347/50 (e=347)
> debug1: restore_uid
> debug1: temporarily_use_uid: 347/50 (e=347)
> debug1: restore_uid
> debug1: Connection established.
> debug1: identity file /u/smf/.ssh/identity type -1
> debug1: identity file /u/smf/.ssh/id_rsa type -1
> debug1: identity file /u/smf/.ssh/id_dsa type -1
> debug1: Remote protocol version 1.99, remote software version OpenSSH_2.2.0p1
> debug1: match: OpenSSH_2.2.0p1 pat OpenSSH-2.0*,OpenSSH-2.1*,OpenSSH_2.1*,OpenSSH_2.2*
> Enabling compatibility mode for protocol 2.0
> debug1: Local version string SSH-2.0-OpenSSH_3.1p1
> debug1: SSH2_MSG_KEXINIT sent
> debug1: SSH2_MSG_KEXINIT received
> debug2: kex_parse_kexinit: diffie-hellman-group-exchange-sha1,diffie-hellman-group1-sha1
> debug2: kex_parse_kexinit: ssh-rsa,ssh-dss
> debug2: kex_parse_kexinit:
> aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour,aes192-cbc,aes256-cbc
> debug2: kex_parse_kexinit:
> aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour,aes192-cbc,aes256-cbc
> debug2: kex_parse_kexinit:
> hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ri...@openssh.com,hmac-sha1-96,hmac-md5-96
> debug2: kex_parse_kexinit:
> hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ri...@openssh.com,hmac-sha1-96,hmac-md5-96
> debug2: kex_parse_kexinit: none
> debug2: kex_parse_kexinit: none
> debug2: kex_parse_kexinit:
> debug2: kex_parse_kexinit:
> debug2: kex_parse_kexinit: first_kex_follows 0
> debug2: kex_parse_kexinit: reserved 0
> debug2: kex_parse_kexinit: diffie-hellman-group1-sha1
> debug2: kex_parse_kexinit: ssh-dss
> debug2: kex_parse_kexinit: 3des-cbc,blowfish-cbc,arcfour,cast128-cbc
> debug2: kex_parse_kexinit: 3des-cbc,blowfish-cbc,arcfour,cast128-cbc
> debug2: kex_parse_kexinit: hmac-sha1,hmac-md5,hmac-ri...@openssh.com
> debug2: kex_parse_kexinit: hmac-sha1,hmac-md5,hmac-ri...@openssh.com
> debug2: kex_parse_kexinit: zlib,none
> debug2: kex_parse_kexinit: zlib,none
> debug2: kex_parse_kexinit:
> debug2: kex_parse_kexinit:
> debug2: kex_parse_kexinit: first_kex_follows 0
> debug2: kex_parse_kexinit: reserved 0
> debug2: mac_init: found hmac-md5
> debug1: kex: server->client 3des-cbc hmac-md5 none
> debug2: mac_init: found hmac-md5
> debug1: kex: client->server 3des-cbc hmac-md5 none
> debug1: dh_gen_key: priv key bits set: 189/384
> debug1: bits set: 531/1024
> debug1: sending SSH2_MSG_KEXDH_INIT
> debug1: expecting SSH2_MSG_KEXDH_REPLY
> debug3: check_host_in_hostfile: filename /u/smf/.ssh/known_hosts
> dynamic linker: ssh: symbol not found: b64_pton
I searched google and b64_pton returned hits referencing BIND on BSD
Is there a library on Skunkware that provides the above symbol?
I had said that 3.1 worked on my 5.0.5 system. Well that was wrong.
I had only tried outgoing ssh to client's systems and that did work.
But I noticed that sshd was not running. I traced the problem to
the PRNGD startup script being set to S98prngd and sshd being set to
S92sshrc. I edited /etc/init.d/sshrc and adjusted the rc2 target to
S99sshrc and that worked on startup.
However, /etc/init.d/pringd fails to get cleaned up when one uses
haltsys to shut down the server: /usr/local/var/prngd/prngd.lock is
not removed and upon system reboot, /etc/init.d/pringd start will
abort when pringd.lock exists. Then if you subsequently use shutdown
to stop the server. /etc/rc0.d/S87prngd sees that prngd is not running
and aborts without removing the prngd.lock file so that S98prngd
fails again on the next startup.