OmniWeb that works with HTTPS?

I know this has been discussed before, but I haven't been able to use any of the help in existing threads to solve my issue.

On my Mac Pro, I've set up the wrp proxy server that allows ancient browsers to surf the web. OmniWeb took to the proxy just fine for http sites, and it's very cool! But most everything's https these days, so I can't browse much with it. I get the error that OmniWeb doesn't know how to handle https URLs.

I've installed packages for openssl, the OmniWeb HTTPS plugin, and everything else recommended. Then I noticed that I have OmniWeb 2.0.x, and the README for the HTTPS plugin mentions OmniWeb 2.75b, so I figured that must be my problem. So I grabbed that from Omni's site.

In short, it fails to launch. I checked the Console and says it's a demo version that has expired. I have also tried OmniWeb 3 and get the same issue.

So, two questions:

1.) Can anyone point me to a version of OmniWeb that's not expired and known to handle https URLs if everything's set up correctly? I believe that I have everything set up correctly but OmniWeb 2.0.x will never be able to use HTTPS URLs. (If I'm wrong on that last part, then I must be missing something else.)

2.) Are there any other NeXT browsers that can handle HTTPS?

My hardware is a mono NeXTstation with a 33 MHz 68040, and I'm running OpenStep 4.2.

Other than javascript/css for the human side of the web, you'll be able to have fun with REST APIs, but to get to the modern TLS standards you're going to have to proxy your plain HTTP into (at least) TLS v1.1 and 1.2.

Haven't tried it yet, but something like this perhaps ? https://wiki.squid-cache.org/Features/SslBump

I have managed to get openssl 1.0.2k to build on OS (i486/m68k) but it's not behaving with CA validation on m68k. Does work on the i486 version of OpenSTEP 4 though.  I have a build of curl 7.54.0 with it, which will work with tls1.2 and will connect, for example, to api.github.com. Not packaged, only a binary.  Trying to see about recompiling the m68k version while I'm typing this...

Hi, i'm not answering the OP's questions, but regarding having HTTPS problems running through WRP, there might have a different cause than support for HTTPS in OmniWeb being missing.

https://drive.google.com/file/d/1agqT8bvswQhOsYS94U2OmnlvCZEin6lb/view?usp=sharing

OmniWeb 2.7b3 in NEXTSTEP 3.3 in VirtualBox in macOS 10.13. WRP is running in macOS.

Note that the URL OmniWeb requests is HTTP and the page WRP renders to image is HTTPS.
This seems right since we count on WRP to do HTTPS work for us.  It implies that maybe somehow the Mac Pro is failing to fetch over HTTPS?  Seems odd.

Again, please note that this approach doesn't add HTTPS to OmniWeb -- it converts HTTPS requests to an HTTP one that returns a clickable image.

Well, if anyone is able to get the following running under NS 3.3 or 4.x on an actual NeXT box, then it'd be solved:
http://oldvcr.blogspot.com/2020/11/fun-with-crypto-ancienne-tls-for.html
Cameron got it going on his HP workstation running NS 3.3. I have CrytoAncienne/carl working on my TurboColor but cannot get micro_inetd to compile, even with the fixes suggested in the git repository....

Packaged quad-fat binaries available here: https://github.com/Asmodai/NeXT-CryptoAncienne/releases/download/1.3/CryptoAncienne-1.3-NISH.b.tar.gz (https://github.com/Asmodai/NeXT-CryptoAncienne/releases/download/1.3/CryptoAncienne-1.3-NISH.b.tar.gz)

Sources to rebuild the package are here: https://github.com/Asmodai/NeXT-CryptoAncienne (https://github.com/Asmodai/NeXT-CryptoAncienne)

Rhapsody build available here: https://github.com/Asmodai/NeXT-CryptoAncienne/releases/download/1.3/CryptoAncienne-1.2-RDR-IP.b.tar.gz (https://github.com/Asmodai/NeXT-CryptoAncienne/releases/download/1.3/CryptoAncienne-1.2-RDR-IP.b.tar.gz)

To rebuild, you require PkgBuilder (I believe this is on one of the Peanuts CDs) and NeXTSTEP 3.3 Dev.

The installer ought to add the relevant entries to /etc/rc.local, but you might want to double-check that.

Once installed, you'll probably want to reboot (or load it manually if you're comfortable with Unix)... then it should just be a case of telling OmniWeb to use http://localhost:8765 as a proxy.

I installed this on NeXTstep 3.3 running in Previous and tried to use it with OmniWeb 2.7. Unfortunately I only get "connection refused" on every attempt to open a web site. This also happens with non-encrypted sites. Maybe you can give some more details on setting this up with OmniWeb? I added http://localhost:8765/ as Proxy Server URL in the Proxy Preferences.

By the way the installer tells that the package is only for Intel but installs it on m68k anyway.

Sorry about that... seems I forgot to add the flag to the makefile to build all 4 archs, so it was only packaging the Intel build.

I've fixed it, published version 1.1 to GitHub, and updated the URLs in my original post.

I think I might improve on it, actually.

With a post-install tool that adds the relevant line to /etc/services and the NetInfo /services directory.  That way, 'micro_inetd' stops being a dependency and one can just use /etc/inetd.conf.   That way, starting the ball rolling is just as simple as sending HUP to inetd.

Thank you! Now it installs the m68k binaries. But micro_inetd does not seem to work with Previous. It just hangs the boot process. That might well be a problem with SLiRP which is not relevant for real machines.

Ok, I might do some playing with that... it might be my snafu, actually.

Can you change /etc/rc.local so it reads:
/usr/local/bin/micro_inetd 8765 /usr/local/bin/carl -p &and then try it?

I shouldn't be allowed to do things when half-asleep.

Though, I honestly don't think micro_inetd is even required.

I'm re-working the install scripts to use niutil to write to the /services directory in the root domain, which should allow the use of NeXT's own inetd.

Great! Seems to boot now without an issue. But within OmniWeb I get a message "execl: Malformed Mach-o file" everytime I try opening a web site.

I'm not sure I prefer messing with NetInfo. It tends to destroy itself to an unrecoverable state. Just removing micro_inetd to recover was simple using single user mode. This won't help with a broken NetInfo database.

Ok, looks like something unexpected might be going on with micro_inetd.  I'll have a play with it on Previous.

I don't buy the whole 'NetInfo is unstable' thing, having maintained a NetInfo server for a considerable number of years with zero issues.

The additions themselves are trivial (3 writes, one to create /services/tlsproxy and the other two to set the port and protocol).

An additional edit to /etc/services is also made for sites that do not use NI.

This allows the addition of a line to /etc/inetd.conf, removing the need for micro_inetd.  Recovery would be as simple as removing the entry from /etc/inetd.conf.

Ok, so it works fine with NeXT's inetd.

On NS3.3 Intel (VMWare):


On NS3.3 m68k (Previous):


Just need to finish testing the package, then I'll put it on GitHub as version 1.2.

Version 1.2 is ready for testing.  I've placed the package at https://github.com/Asmodai/NeXT-CryptoAncienne/releases/download/1.2/CryptoAncienne-1.2-NIHS.b.tar.gz (https://github.com/Asmodai/NeXT-CryptoAncienne/releases/download/1.2/CryptoAncienne-1.2-NIHS.b.tar.gz)

If there are any issues, the first thing to try will be sending inetd the HUP signal:
# (as root)
ps auxw | grep '(inetd)' | grep -v grep
kill -HUP <pid_of_inetd>

If that doesn't resolve anything, well, we'll interactively debug that bridge when we get to it.

As a bonus, I've also compiled it for Rhapsody (both i386 and ppc)



I don't want to use TinyInstaller, as I don't think that's capable of install hooks, so I'm working on an installation shell script for it.

I'll post it here as soon as it's ready.

That is fantastic! Thanks so much!

By the way, maybe there is little reason to do this with emulators, but I remember back in the day I set up DHCP on my NeXT cube. It was a pain. I think I still have the package, but I had to make weird edits to etc, if I recall, to get it to work. And every mistake was a big pain in the butt. But, once set up, DHCP worked great.

Did you try/get DHCP working on your builds?

No, all of my NeXT systems are managed by NetInfo and have static IPs.

I do recall doing DHCP at some point, but this was over 15 years ago, so I have next to no memory of it.

I seem to recall TjL had a document on setting up dhcpcd on NeXT, didn't he?

Thank you for the new version! This one seems to finally work (or I just missed to add the protocols in the Proxy Preferences before).

Most pages do not render very well, which is of course due to OmniWeb 2.7 not supporting recent features. For those browsing the web using NeXTstep I can recommend http://www.frogfind.com/ (http://www.frogfind.com/) as an alternative. It is a search engine that also accepts URLs. Not only does it work without https but it also converts pages to plain text. The results are mostly better than what OmniWeb renders from recent pages.

But of course CryptoAncienne is the way to go for pages that do render correctly with OmniWeb!

Little question: Is it normal that it mostly does not load images using OmniWeb 2.7? I tried the NeXT Wikipedia page that is shown in your screenshots and it does not load a single image.

Update: OmniWeb tells me "Server returns "Proxy Error"" for the images.

I'm not entirely sure... I suspect it's something to do with the rendering engine, because when I click on an image to get at the raw jpeg:


yet, when looking at the image + metadata:


OW3 does a better job:


So I'm going to assume it's something specific to OW2's renderer.

_{(also, I need to hack together a backspace module for Steve's 'The Look'(tm), that should stop anyone from messing with my stuff when I'm afk!)}

It seems that some pages do not render correctly due to timeouts: "Proxy Error Content-type: text/html Timeout". I suspect this also being the reason for the missing images.

Update: Things improve when I give Previous some extra speed using variable speed mode. Some images render and pages are "more complete". But still some pages only render partially and most images are missing. There is definitely some problem with timeouts.

I'm wondering if the next avenue would be a bundle for OmniWeb, so that it doesn't need to use a proxy.

Though, it might just be better to take another rendering engine (such as NetSurf) and figure out how to render that to Display PostScript.

Rhapsody DR2 binaries:  https://github.com/Asmodai/NeXT-CryptoAncienne/releases/download/1.2/CryptoAncienne-1.2-RDR-IP.b.tar.gz (https://github.com/Asmodai/NeXT-CryptoAncienne/releases/download/1.2/CryptoAncienne-1.2-RDR-IP.b.tar.gz)

I have not tested these on Rhapsody DR1 or anything newer than Rhapsody DR2, so ymmv.

I was able to solve the timeout problem. In inetd.conf I added the -t option (no timeout):
tlsproxy stream tcp nowait root /usr/local/bin/carl carl -p -t
Pages now render completely. Images are still mostly missing and OmniWeb is telling me "Server returns "Proxy Error"" inside the Processes panel while trying to load those images.

I've added the `-t` option to the install script.  Updated version available at:

https://github.com/Asmodai/NeXT-CryptoAncienne/releases/download/1.3/CryptoAncienne-1.3-NISH.b.tar.gz (https://github.com/Asmodai/NeXT-CryptoAncienne/releases/download/1.3/CryptoAncienne-1.3-NISH.b.tar.gz)

Please be sure to uninstall any previous version first, or it will leave inetd.conf alone.

Thank you for the update! Just a minor note: The uninstaller seems to first delete some directories and then tries deleting files, that have been inside those directories and are already gone. Here is the log of Installer.app:

Checking permissions for the files in CryptoAncienne.pkg ...
    Checking /usr/local/bin/carl ... OK.
    Checking /usr/local/bin/micro_inetd ... OK.
    Checking /usr/local/man/man1/carl.1 ... OK.
    Checking /usr/local/man/man1/micro_inetd.1 ... OK.
    Checking /NextLibrary/Receipts/CryptoAncienne.pkg ... OK.
... done.

Deleting CryptoAncienne.pkg from /usr/local ...
    Running deletion program ... Removing /services/tlsproxy from NetInfo.
Restoring /etc/services from backup.
Restoring /etc/inetd.conf from backup.
Sending HUP to inetd (135)
Done.
    Deleting /usr/local/ ... OK.
    Deleting /usr/local/bin/ ... OK.
    Deleting /usr/local/bin/carl ... not found.
    Deleting /usr/local/bin/micro_inetd ... not found.
    Deleting /usr/local/man/ ... OK.
    Deleting /usr/local/man/man1/ ... not found.
    Deleting /usr/local/man/man1/carl.1 ... not found.
    Deleting /usr/local/man/man1/micro_inetd.1 ... not found.
    Deleting /NextLibrary/Receipts/CryptoAncienne.pkg ... OK.
... done.

Maybe it would be better to not delete those directories at all in case some user has other data inside them.

The pre-uninstall script makes no attempt to do anything with files in /usr/local... it only looks at (and twiddles) NetInfo, /etc/services, and /etc/inetd.conf.

I believe what you are seeing is the default behaviour of NeXT's Installer app -- though will leave the directories present if they are non-empty (I have lots of stuff in my /usr/local)

On a separate note.

I suspected HTTP 1.1, so I added `-s` to carl's options.

I didn't really notice anything on Intel (OmniWeb 2 still doesn't show images), but it might be a slight performance increase.

I've yet to test on NEXTSTEP 3.3 m68k.

Interestingly, OmniWeb 3.1rc2a on OPENSTEP 4.2 m68k renders fine:



though it did take 5 minutes.

Quote from: verdraith on January 08, 2023, 10:45:58 AMI believe what you are seeing is the default behaviour of NeXT's Installer app -- though will leave the directories present if they are non-empty (I have lots of stuff in my /usr/local)

Thank you for the explanation! That is reassuring.

Quote from: verdraith on January 08, 2023, 10:45:58 AMthough it did take 5 minutes.

If running m68k NeXTStep in Previous you can speed up things by setting the CPU to variable speed mode (System > Customize). On my M1 Mac mini it speeds up OmniWeb by a factor of about 5!

Verdraith, sir - thank you so much for diving into CryptoAncienne! I'll have to take another crack at it - I never did get micro_inetd to compile on my TurboColor under NS 3.3 with the stock NextStep developer install (I've not tried upgrading the compiler), though carl works fine. And somehow failed to set NI and/or inetd.conf correctly to get inetd to start carl up when OmniWeb needed it (it really ought not be much of a problem...). I also tried to run things on a PPC G4 iMac using Cameron's Rphapsody build but OmniWeb on the NeXT didn't seem to want to connect to that either (and I'm running strictly static IP addrs as well)...

You're welcome!

It was a fun experience, and hopefully the results are useful to people.

OK, some results: it is working with OW 2.7b3 on my 25MHz mono station under NS 3.3. As with Andreas, I see no images on the few sites I've tried as yet. But some success!

However, 'carl' dies with a bus error when running it under NextStep 3.3 on my SPARCstation 5 - which is also the result I got last year when I compiled an earlier version (1.5). Sigh. I'll see if I can figure out how to set 'gdb' on it...

But we now have another tool for our antique (but futuristic) OS, along with frogfind.com, wiby.me (with https sites filtered out in settings), theoldnet.com (& it's /lite version), to get around the WWW that was first implemented under NextStep. It's only just....

I think it would be great to have "carl" run as an extension for OmniWeb. I think it supports plug-ins or something similar? Maybe that would also solve those problems with missing images, which seem to be related to proxy timeouts.

I have not yet had a chance to truly experiment with this, but we do have to remember that it's likely that OW 2.7 likely can render only a few types of images - JPEG & GIF most probably, perhaps PNG. SVG - quite unlikely, and I think those are used quite often on Wikipedia, for example.
A bundle containing an SSL/TLS extension that OW can hook into is indeed what Juergen Mollenhof put together long ago and gets installed in /LocalLibrary/Omnicomponents. His last version, 1.05, used a (now ancient) version of OpenSSL (succeeding the SSLeay lib) and gave us TLS 1.0 or 1.1 (such that one can still peruse/post on the nextcomputers.org forums with OW 2.7). I have never seen any documentation as to how a bundle is created. It may be that a newer version of OpenSSL can be compiled for NS 3.3 and the bundle recreated.....and, who knows, perhaps a bundle for conversion/display of images in formats lacking in OW could be created? Perhaps we need to contact the folks at Omnigroup to see if any documentation (or heck, source code) for OW 2.x still exists...

I wonder if OmniComponents for 2.x is on a Peanuts CD.

-- edit --

Actually, scratch that... looks like it's just a bundle, and the https bundle sources already have the relevant files.

Images, on the other hand... those might require sources.

Most sources I have from Omni are from between 1998 and 2001, so no doubt those are for OPENSTEP -- OmniAppKit, OmniFoundation, OmniNetworking, OWF etc etc.

That means I can do stuff for OmniWeb 3 at least.

For OW2, I'd probably need whatever equivalent SDK(s) exist for that, which I can't seem to locate.   If we can't collectively locate them, I'm tempted to reach out to Omni.

With help from crimsonRE, we've tracked down version 1.05 of the OW2 HTTPS extension.  It comes with sources and looks more sophisticated than what's in HTTPS 0.5.

However, there is a caveat.  Although it's a bundle with no dependencies in the makefile, the sources make use of things from Foundation, OmniFoundation, OmniAppKit, and OmniWeb.

I already have the backport of Foundation that NeXT did for NeXTSTEP, but it seems the Omni code I have is for OPENSTEP.

I've fired off a mail to OmniGroup's support mail, so hopefully that'll either really confuse them, or make them laugh and (hopefully) point me in the right direction.

Also, hidden away on the FTP server on which the NeXTSTEP extension is located are the sources for the OPENSTEP and Rhapsody versions of the extension :)

Very nice, sir - excellent find!

I played a bit with OmniWeb - natively displays TIFF, GIF, JPG and PNG images. I seem to see OW displaying images hosted on the particular website being visited but images being pulled in from a third-part server are often not being shown.

With 'carl' running, my TurboColorstation goes to a huge load level (>10!) when a large images from a website are being processed by OmniWeb...definitely different behavior than ever before....

It seems that building a plugin for OW2 might not be the road to travel down.

Using 'class-dump', I have built up enough of the 2.7b3 API to compile the HTTPS plugin, but OmniWeb won't fully load the bundle due to undefined symbols.

I suspect Omni might no longer have the required headers to build the plugin.  Protocol plugins for OW2 might also be hairy.  Mr Case informs me that Omni factoring the Gopher code into a plugin is what drove them to redesign OmniWeb's architecture and produce OmniWeb 3 in the first place.

I'm going to continue hacking at it to see if I can progress, but I think a viable alternate is something that's worth planning for.

So, I'm curious as to what 'modern' hardware you guys rock with.

It might be better in the long run to build a proxy server around a C or C++ port of Readability (the same stuff FrogFind uses), and package that for semi-modern systems... Solaris, BSD, GNU/Linux, and macOS.

That would lead to various solutions that allow any older browser to work:

• Docker container image,
• RPM packages for RedHat, Alma, CentOS et al,
• Deb packages for Debian, Ubuntu, Raspberry Pi OS et al,
• macOS binary that can be put on a Mac Mini or some such,
• Prebuilt minimal GNU/Linux appliances for the likes of ESXi or any other hypervisor.

Suggestions, ideas etc are more than welcome.

Im curious why bother with OmniWeb 2.x series and not use whatever is their latest, assuming that is OW3.x?

OmnWeb 3.x runs only on OpenStep 4.x. OW 2.7b is the final version released for NextStep 3.3...

I see. But you may remember. If you install OPENSTEP4.2 over NEXTSTEP 3.3, it will keep all the NEXTSTEP 3.3 libraries. It keeps both sets that way. If you do just a clean install of OS and not as an upgrade over NS3.3, then you do not get the NS3.3 libraries.

So I guess, to me, there is little reason not to go to OS4.2, it seems super inclusive of everything coming before and extends abilities to newer apps like OmniWeb3

I guess OS is a bit 'chunkier' than NS, so perhaps people want to keep things running as lean as possible. But in that case, you can go back, I guess, to NS2 and 1 as well.

OPENSTEP 4.x includes the NEXTSTEP libraries for backwards-compatibility with NEXTSTEP 3.x applications.

The caveat with OS 4.x is that although you can run NEXTSTEP 3.x apps, you cannot write apps using the the old appkit.

I think in general it's wrong to say 'yeah, just ensure you're using OPENSTEP 4.2.'  A solution should encompas anything... including WorldWideWeb/Nexus on NeXTSTEP 2.x :)

So, the question still stands... besides NeXT, what other hardware do you all have available that's modern-ish enough for a C99 compiler and POSIX? :)

Also, I really like the idea of using a Raspberry Pi.

-- edit --
Just to be clear, I'm not ruling out writing a thing for m68k NeXT hardware, I just think any solution should be generalised to the point where it could be used by any part of the retrocomputing community for any browser on any OS on any hardware, not just NeXT.

There are a few things that you end up missing if you just do a straight open step install and not do the upgrade.

Perhaps it's the developer library's aren't fully brought over?

And there's, some thing to do with the capabilities of some software.

It might be the real time RenderMan, for example and parts of it that are built into the operating system won't be there. It might have something to do with licensing, so the only way to get the carryover was to do the upgrade over next step 3.3.

Yes, you don't get the NEXTSTEP AppKit headers, IndexingKit headers, or DBKit headers -- DBKit is moot given that EOF is a thing.

You also don't get Quotations.app, which is probably a MAJOR issue for most people.

There are some other minor differences between the two, but for the most part, unless you have a specific reason, a full install of OPENSTEP 4.2 will run the NEXTSTEP 3.3 apps that you require.

With all that said, I still don't believe 'use OPENSTEP 4.2 so you can use OmniWeb 3.1' is a solution for most people (myself included).

I agree that any solution should include NeXTStep 3.3 and OmniWeb 2.7. Besides from real hardware maybe one possibility would be to build this into Previous? It already has an internal NFS server. So adding something like an internal decryption service might be possible.

Quote from: andreas_g on January 26, 2023, 12:33:02 AMI agree that any solution should include NeXTStep 3.3 and OmniWeb 2.7. Besides from real hardware maybe one possibility would be to build this into Previous? It already has an internal NFS server. So adding something like an internal decryption service might be possible.

That's a nice idea.  Having Previous provide a proxy that can handle HTTPS and also do mapping of HTTP {0.9,1.0} to HTTP 1.1 could be a win.

Once I'm done with the NXBench port, I'm going to start experimenting with the idea of a proxy running on some other host.  I'll keep the code at C99 with POSIX.1, that way it can be easily ported to just about anything (except exotics like VMS, TOPS-20, TWENEX etc.)

Quote from: verdraith on January 26, 2023, 12:20:53 AMYes, you don't get the NEXTSTEP AppKit headers, IndexingKit headers, or DBKit headers -- DBKit is moot given that EOF is a thing.

You also don't get Quotations.app, which is probably a MAJOR issue for most people.

There are some other minor differences between the two, but for the most part, unless you have a specific reason, a full install of OPENSTEP 4.2 will run the NEXTSTEP 3.3 apps that you require.

With all that said, I still don't believe 'use OPENSTEP 4.2 so you can use OmniWeb 3.1' is a solution for most people (myself included).

I'm pretty sure you lose real-time fender man too, but I'm going off memory which is always dangerous.

Sorry, I don't understand. Why is open step not an option for you? I think it runs on all machines that support next step 3.3?

It's not an option because I choose to run NEXTSTEP 3.3 :)

Besides, I already have a couple of OPENSTEP 4.2 installs... and an OPENSTEP 4.0 PR1 'Mecca' install... and a Rhapsody DR2 install.

In my humble opinion, the 'just upgrade to xyz' argument can be applied to its logical extreme.  Why are you not using macOS 12 or Windows 11 or the latest GNU/Linux distro?  That's not what retrocomputing is about.

Quote from: verdraith on January 26, 2023, 08:07:02 AMIt's not an option because I choose to run NEXTSTEP 3.3 :)

Besides, I already have a couple of OPENSTEP 4.2 installs... and an OPENSTEP 4.0 PR1 'Mecca' install... and a Rhapsody DR2 install.

In my humble opinion, the 'just upgrade to xyz' argument can be applied to its logical extreme.  Why are you not using macOS 12 or Windows 11 or the latest GNU/Linux distro?  That's not what retrocomputing is about.

That's easy to answer. macOS has a completely different and mostly worse, to me, UI. It's bloated by multiple orders of magnitude and yet does not offer that much more functionality and is missing some. Like real-time renderman OS support or a lowly workspace processing panel...or system wide lip service... etc etc.


That said, the "I want to" argument is more than sufficient. I was trying to understand if there was some technical issue/limitation.

I'm curious why you prefer 3.3 to OS4., if you don't mind sharing? The UI is basically the same. Libraries and OS do feel a little more bloated.

Quote from: zombie on January 26, 2023, 08:19:35 AMI'm curious why you prefer 3.3 to OS4., if you don't mind sharing? The UI is basically the same. Libraries and OS do feel a little more bloated.

I think I should explain a bit about my setup here.  Maybe things will make sense.

Node	OS	Function
nova	OPENSTEP 4.2 Intel + EOF + WOF	NetInfo master, User homedir NFS server.
dauntless	NEXTSTEP 3.3 Intel + EOF + foundation	Dev box NS-specific stuff.
galaxy	OPENSTEP 4.0 Intel 'Mecca'	Super funtime stuff!
grissom	OPENSTEP 4.2 Intel	Plain OpenStep dev box.
oberon	OPENSTEP 4.2 Intel + EOF + WOF	EOF/WOF dev box.
saratoga	Rhapsody DR2 Intel	Yellow Box dev box.
fearless	Windows NT 3.51 + OpenStep Enterprise 4.2	dev box.
courage	Windows 95 + OpenStep Enterprise 4.2	dev box.
gagarin	Windows 98 + Yellow Box 5.1	dev box.
eisenberg	Windows 2000 + WebObjects 5.1	dev box.
kuznetsov	Windows XP + Yellow Box 5.1	dev box.

(I've omitted my various Previous stuff, such as NeXTstep 0.8, 0.9, 1.0 etc)

I haven't built any PA-RISC or SPARC systems for either NEXTSTEP or OPENSTEP, but that's on the Todo List(tm).  I'm currently setting up a qemu-sparc VM for Solaris 2.5.1 + OpenStep Solaris.

I have other systems (both virtual and physical) too..  I could describe those if anyone's interested.

Quote from: verdraith on January 26, 2023, 09:36:08 AMI think I should explain a bit about my setup here.  Maybe things will make sense.

Node	OS	Function
nova	OPENSTEP 4.2 Intel + EOF + WOF	NetInfo master, User homedir NFS server.
dauntless	NEXTSTEP 3.3 Intel + EOF + foundation	Dev box NS-specific stuff.
galaxy	OPENSTEP 4.0 Intel 'Mecca'	Super funtime stuff!
grissom	OPENSTEP 4.2 Intel	Plain OpenStep dev box.
oberon	OPENSTEP 4.2 Intel + EOF + WOF	EOF/WOF dev box.
saratoga	Rhapsody DR2 Intel	Yellow Box dev box.
fearless	Windows NT 3.51 + OpenStep Enterprise 4.2	dev box.
courage	Windows 95 + OpenStep Enterprise 4.2	dev box.
gagarin	Windows 98 + Yellow Box 5.1	dev box.
eisenberg	Windows 2000 + WebObjects 5.1	dev box.
kuznetsov	Windows XP + Yellow Box 5.1	dev box.

(I've omitted my various Prevous stuff)

I haven't built any PA-RISC or SPARC systems for either NEXTSTEP or OPENSTEP, but that's on the Todo List(tm).  I'm currently setting up a qemu-sparc VM for Solaris 2.5.1 + OpenStep Solaris.

I have other systems (both virtual and physical) too..  I could describe those if anyone's interested.

Oh I see. Youre not building single 'to rule them all' machine as much as an army of 'collect them all' machines! :D

Makes sense. Thanks!

Quote from: zombie on January 26, 2023, 09:39:49 AMOh I see. Youre not building single 'to rule them all' machine as much as an army of 'collect them all' machines! :D

Not so much 'collect' them all... more like 'hack on them all' :)

I write code for most of the retro stuff I have.  It's often frustrating -- trying to deal with POSIX and X/Open and oftentimes a lack thereof.   And that's not even bringing up such systems as ITS, TOPS-20, VMS etc (which, alas, I don't use these days... maybe I should bring up new systems on an RPi for those.)

There's also this:


Yes yes, that is Microsoft Word... and yes, it is running on Unix (SCO OpenServer v5.0.3 to be exact)... but I mean the DEC VT510 terminal in this case :)

Do love an amber screen. I set all my terminal windows on every machine to either green or amber - there are definitely good reasons for doing so (save power/phosphor and eyestrain).

Quote from: verdraith on January 08, 2023, 09:59:40 AMI've added the `-t` option to the install script.  Updated version available at:

https://github.com/Asmodai/NeXT-CryptoAncienne/releases/download/1.3/CryptoAncienne-1.3-NISH.b.tar.gz (https://github.com/Asmodai/NeXT-CryptoAncienne/releases/download/1.3/CryptoAncienne-1.3-NISH.b.tar.gz)

Please be sure to uninstall any previous version first, or it will leave inetd.conf alone.

I'd like to give this a try on my cube with NS3.3 @verdraith !


Is it simply a matter of installing the package as root, rebooting and then configuring omniweb to use http://localhost:8765/ as a proxy server?

Thanks!

That's pretty much it, yes. The package does all the heavy lifting.

(However: it is extremely slow; you're looking at 10-60 seconds per page load. I've had much better performance running carl on a modern POSIX box following these (https://system7today.com/setup-crypto-ancienne) instructions.)

Ah interesting, thanks.

So you follow those instructions on something like a raspberry pi, and then point the omniweb proxy settings to port 8765 on that Pi?

Well, you can pretty much pick your poison at that point—I have it running on my webserver, but configured to ignore requests from anywhere but my home IP. If I ever go on the road I can just allow incoming connections from another IP temporarily.

Hmm, ok, gave this a go. I followed the instructions on my RPi4 and the xinetd service is running, but trying now to connect omniweb to https://www.google.com returns a 'connection refused' response from omniweb.

I've included http://localhost:8765/ and http and https into the preferences of omniweb as per the pic earlier in this thread, but that doesn't alter omniwebs problem!

I think the issue is I don't really know what I'm doing, so I'm stumbling around in the dark somewhat :D

I guess I need to check if it's router issue (can't think why, but maybe I need to forward the 8765 port?), check to see if xinetd has a log file and / or a debug mode, and double check what omniweb is doing. Jobs for later!

Simple fix—"localhost" refers to the computer itself, in this case your NeXTcube. You'll need to replace it with the IP address of your Raspberry Pi.

I did try that, as localhost didn't make sense to me (same as putting in 127.0.0.1? ), but that didn't resolve the issues either. The pi has ip address 192.168.0.54 and is on the same subnet as the cube.

ok, sorted it :)

Looking in /var/log/syslog I noticed these two suspicious looking lines once xinetd service has been started:

service/protocol combination not in /etc/services: carl/tcp
Started working: 0 available services

It seems that the following line has to be appended to the carl script:

type            = UNLISTED

Now when I restart the service the log shows this:

Started working: 1 available service

And voila! My cube can now use the proxy!