The PiDP11 is a scale model of the PDP11 front panel, complete with working lights and switches, all driven by the SIMH software running on a Raspberry Pi.

It was designed by Oscar Vermeulen, who sells it as a kit for the hobbyist to build and enjoy. I bought my kit last summer, but due to the home renovations did not build it until Christmas.

Oscar and others have developed software for it that customizes SIMH and drives the lights and reads the switches. There is also a marvelous manual describing how to build and operate the kit in great detail.

There’s been one problem: the front panel occasionally locks up. There was a lot of discussion on the PiDP11 discussion forum, and several causes and solutions were offered and discussed.

Eventually the source of the lock-up was traced to a race condition in one of the files controlling the front panel. A corrected version of the file was provided in February 2019, and I finally got around to installing it (and recompiling the software) on May 22. It ran until May 28, when it locked up again.

I reported this to the group, and one of the developers (Bill) modified the source file to try and fix the problem permanently. The fix was only offered as a set of lines to edit and recompile rather than a new file to keep versions clean. The fix was posted yesterday (May 29)

Today (May 30), I edited the source file and recompiled, then rebooted the PiDP11 at 9am. The main purpose of this post is to document the date & time of this latest fix in the event it does not lock up again. I can then refer back to this post for the date/time the fix was made.

As the title says, really, really messy.

It’s not wordpress’s fault. Rather, wordpress is keeping up with the times, and the times say PHP needs to be kept current.

Up until the last version of WordPress (5.2), my OpenBSD server created many years ago was OK. It’s version of PHP was old, but it worked. When I updated to 5.1, WordPress warned me that my PHP was obsolete, but there wasn’t much I could do at the time. My old version of OpenBSD did not have a simple path to update PHP. Rather, to update such things one is expected to update OpenBSD.

Then came WordPress 5.2. My existing WordPress stated “cannot upgrade due to older PHP” or something similar.

Time to update PHP, which meant a new OpenBSD.

That’s when Messy happened. The latest OpenBSD (6.4) is wonderful. It’s shiny and new and fast, but … they replaced Apache with a new program ‘httpd’ that was written to be ultra-secure. Too secure, in fact.

I spent two weeks fighting OpenBSD 6.4 and httpd, but could not get it to do what I needed. Worse, there’s almost zero helpful documents written about it. The manual is OK but dense, and the only “how to” site covered setting up the ultra-secure version, and nothing else.

Yesterday I finally gave up. Instead of updating OpenBSD, what if I just modified the firewall to scoot all the apache pages to a new server? Something like Ubuntu 18.04 that I’d recently put on all my tomcat/jupterhub servers? Would it be as difficult as OpenBSD?

I found a couple of how-tos, and they seemed utterly simple. “apt-get install apache2”. Done, and it was running! “apt-get install php”. Done, and also running. “apt-get install mysql” (this was for a virtual test server). Done and running. This was scary easy.

Even configuring Apache has gotten much easier due to the plug-and-play structure that’s been adopted (probably for some time).

The only difficult part was installing wordpress. It really wants to be in one place, and doesn’t like port forwarding. For example, if the test server was “http://10.1.1.214”, then that’s where wordpress wanted to be. Port forward “http://huntrods.com:8008” and it just reverted to either 10.1.1.214 or “huntrods.com” and didn’t work. Eventually I realized that port forwarding would happen when I threw the “big switch” and turned off the current (old) server.

With that in mind I did some more testing on WordPress – duplicating this blog from database backup and latest wordpress. It hated the older version and refused to run, but copying over the latest files did the trick.

Finally the big moments: install apache2 and php on the physical server, create the various accounts necessary for users, then copy all the files from the old server to the new server. Most were static web sites, but there were 3 wordpress blogs that had to come over, complete with new databases (from today’s backups).

At last it was all working locally. Time to throw the switch. On the OpenBSD server, I stopped the old apache and disabled it, then forwarded port 80 to the new server. SUCCESS, or at least partial success. I still needed to create all the Virtual Hosts from before, but with the plug-and-play Apach2 that turned out to be easy if time consuming.

Lastly I fired up the WordPress accounts, and they failed. It turned out I had to copy “latest.tar.gz’ over the older WordPress files and then everything worked.

So after two weeks of fighting httpd, I was able to get Apache2 working on an Ubuntu server, complete with full testing, in just under two days.

Success, indeed.

I’ve been using OpenSDK Java (Java 11) on my Ubuntu servers for a while now, so thought it would be a good idea to update Java on my main production machine.

After digging into “what’s the difference between OpenSDK and Oracle SDK”, I came to the conclusion the main difference was … nothing. Since it was a lot easier to find Oracle SDK for a Win 7 box, I chose that and downloaded the installer.

After installing… nothing. It was still pointing to the older version. I removed the older version(s) and still… nothing. I reinstalled and there was a “next steps” button which led to a help file that basically said “you must manually adjust the system PATH variable for Java to work”. Really? In 2019???

Oh well, it’s easy to do and afterward I did indeed have Java 11 running. I also updated my ‘go.bat’ script that sets up Java for command shell compiling, which is used by my production ant builds of my enterprise application.

Of course, the ant build failed, but I knew it would as the (very old) libraries were removed when I toasted Java 8.

And now came the messy part. I pointed CLASSPATH to the new (better) Tomcat location of the various servlet libraries, but still no good news. After much reading to little effect, I grabbed some of the code and tried compiling it in a shell window, which worked just fine. I had established that ant was not getting the CLASSPATH.

In the midst of this I upgraded Apache Ant to version 10 with no ill effect.

Again, after much more reading, it became clear that Ant actually and openly HATES the classpath variable and erases it when used. There was no functional work-around to this, so I reluctantly rewrote my build.xml files to embed a classpath for the application compiles. This worked, but showed more missing files.

I adjusted the Ant build until everything compiled, but it required a new ‘altlib’ directory of lesser-used jar files to fully work.

Finally, an almost-good compile. There were only a few remaining errors, but they ended up costing me time. All errors amounted to the removal of “com.sun” libraries. One was found in apache.commons, and the other was so deprecated that the advise just said “comment it out”. I did, and everything compiled successfully.

Now I’m running on Java 11 and Ant 10 with what is considered a “proper” build link to libraries. I disagree but there’s little I can do.

I have been running industrial strength servers for many years now, as part of a project that has been moderately successful.

The current set of servers are 1U rack-mount ‘pizza boxes’, most quad-core xeon Intel servers, and one dual-CPU AMD Opteron. All are Hewlett Packard (HP) Proliant servers from roughly 2005. All have been running without major incidents, many of them since 2005.

About 2 years ago the dual Opteron died in production. No warning, it just up and died. I got the call in the morning and went and retrieved it from the co-locate service by lunch. Basically I just took one of the quad-core Xeons with all the software ‘ready to go’ and did a box swap.

Once home I didn’t spend much time on it, but a few reboots seemed to confirm a hard drive problem.

Fast forward to just before Christmas last year. I wanted a box to run JupyterHub on Ubuntu, and this box with it’s dual AMD processors and 16GB memory seemed a quick prospect.

After various diagnostics, I determined the hard drive was OK, but the SATA system was not. I managed to install Ubuntu from a burned DVD iso, but it took a very long time and then didn’t reboot successfully. I shelved the server at that point and went instead with a brand new purpose built server, which works wonderfully.

In late January I wanted a server to run OPM – an open source reservoir simulator. I’ve run it before on virtual machines, but wanted a ‘real’ server. I pulled out the dual Opteron and tried installing Ubuntu again, this time from a known good USB data key that I’d used on the JupyterHub purpose-built box. This time it installed quickly and rebooted to an operating system.

I installed it in my newly built server rack and after moving everything to the server room it fired up and has been running since.

Late last week Ubuntu updates indicated a reboot of all my Ubuntu systems was needed. All except the dual Opteron rebooted without incident. Unfortunatly, the dual Opteron would not boot, instead returning to the dreaded “SATA channel X is slow to respond…”. Eventually this fails with “SATA channel is down” and no hard drive.

It’s annoying as the POST clearly shows a SATA HDD as expected. It’s only on OS boot that SATA dies.

I decided to diagnose and fix the problem if I could. I started by pulling the cover and then tried a few boots – no good. I then pulled all the cables and eventually pulled the HDD and set it all on top. This time it booted without a hiccup! I verified all was good with a few proper shutdowns and then cold boots, and proceeded to replace all the cables and button up the case. And… the boot failed.

After much checking and rechecking, I had this niggling feeling in my brain that there was ‘something up’. At one point when it was failing to boot (at the “SATA channel X is slow to respond…” I pulled the mini-power connector off the optical drive. INSTANTLY the boot process proceeded normally.

I tested this a couple of times to confirm, and indeed the problem is the optical drive (DVD ROM). Specifically, the optical drive is a removable mini-height drive that unclips and slides out of a circuit card. The circuit card stays in the machine, and has a 36pin IDE header plus the micro-power connector. Pulling the power connector kills the drive electronics and allows the machine to boot cleanly.

It would seem that somehow the single IDE channel for the DVD ROM optical drive is interfering with the SATA channels for the HDD. That or there’s a power drain when the DVD ROM is plugged in that messes with the power to the HDD. Both HDD bays and the Optical drive share the same power harness. Power to the DVD splits off the power connector for one drive, but all are on the same set of wires from the power supply. It’s possible there’s a drain that kills one of the power lines. Unfortunately with the HDD in place you cannot tell if it’s spinning or not.

However, I don’t really think that’s the issue. Before Christmas one of the problems I experienced was the utter slowness of the DVD ROM to read the known-good disc. I suspect the DVD ROM electronics are bad and somehow influence the SATA controller. For all I know it’s the same chipset on the motherboard.

At any rate, the machine is now back together and running perfectly – just with the DVD ROM power cable disconnected.

It was very difficult to diagnose, but I’m glad I was able to finally solve the mystery.

OK, this does seem like a bit of a back-pedal, doesn’t it?

Well, that’s the thing about the “Linux Model” – the very things that are so irritating can also be the reason it works.

Let me explain by returning to one example I mentioned in my prior post, using C++ in Jupyter Hub.

To recap: C++ used to work in Jupyter Hub, then suddenly stopped after an update of some packages in Conda. Conda is the environment that manages Jupyter Hub, and works a lot like apt-get for Linux. After one update, all things C++ failed to the point the kernel would not load at all. An examination of logs revealed <features.h> was missing as well as many other library errors.

Simple google search revealed many with similar (but NOT the same) problems, and many complicated workarounds.

This is one of the problems with the Linux Model. The many “solutions” can often make the problem infinitely worse. Worse to the point you throw up your hands and just rebuild from scratch, which most certainly did NOT want to do. Part of the problem is that “solutions” can come from anyone in the community: seasoned pros, or first-time amateurs. Most don’t document what they are doing very well, and so you make assumptions… and get in worse trouble.

The Linux Model solution is to try and find an authoritative source. Usually this means contacting the team that developed the “thing” that’s broken. Often (and again a failing of the open Linux Model) the team has moved on to other things and really doesn’t care or maintain the broken thing. In such cases, you are pretty much hooped unless you can get the code and love delving into ancient artifacts.

It also requires a LOT of digging in many cases to find the team, or else… EXPERIENCE knowing where to look.

Fortunately, I was beginning to obtain that experience. (and NO, it’s most definiely NOT the group of Stack Overflow websites, but that opinion is for another day). After starting with Jupyter Hub, I began noticing that a lot of the projects were hosted on github.com. I’ve used github before, but only to download/install things. With Jupyter, I began noticing a lot of activity happening on the “Issues” tab. Here I discovered the magic: if the project was active, the developers READ the issues and would comment/reply.

Knowing this, I returned to my C++ problem. I found the package on github, and used issues to contact the team with my problem…. “it’s busted” but stated more “unix like” 😀

Within an hour one of the developers contacted me to say they’d changed the way they distributed the package for the very reason I mentioned (C++ library problems). They rewrote the distribution and moved the code from a custom source to the Conda standard source “conda-forge”. However, the old code was still “out there”. I was told to grab the new code and it shoudl work.

I did this, and it didn’t work. However, having chatted with a developer, I simply updated my “Issue”. The next day I received a reply: remove EVERYTHING from the old distro source. Using “conda list” I could clearly see MANY packages (not just the base C++ package) came from the “now bad source”. After removing all of them and reinstalling the main package from the proper source (conda-forge), I tried my C++ example and it worked perfectly.

So the Linux Model does work, but you have to do a lot more homework and find the place where the developers’ hang out with the current code.

For Tomcat, that’s the Tomcat-users or Tomcat-devel list group. For my 8-bit computer replicas, that place is some specific google groups. For most things involving Jupyter Hub, that place is the appropriate github.com repo (and the Issues tab).

My final thought for now on the Linux Model is that it does work for almost anything current. The big bonus is there is often a HUGE community of active developers who really want their work to be appreciated and used. Find them, and ask properly worded respectful questions, and you can see the Model work beautifully.

This is about LetsEncrypt, JupyterHub and Tomcat.

I built my JupyterHub server on a quad-core xeon 1U ‘pizza box’ server I had spare. It’s short on memory because this generation HP Proliant server maxed out at 8gig, so that’s all I can put in it. Still, it works and is a good demo platform for JupyterHub and my Java course revision project.

JupyterHub really wants to be running as secure HTTP (HTTPS) with a proper certificate. I put the server on a different port (not 443) but can still reach it from my domain, using packet-filter redirection in my firewall.

But – it wants that proper certificate. Typically one would just create a ‘self-signed’ cert using Java’s keytool and use that for Tomcat, but Jupyter wanted something else.

Fortunately I found enough documentation and tutorials to enable me to install and generate a LetsEncrypt (free) certificate that worked perfectly with JupyterHub. There were issues, mostly involving the need to create the certificate manually, but once these were resolved it worked perfectly.

This past week I wondered “could I use the LetsEncrypt certificate with my Tomcat application?”. I searched the web, and found several rather conflicting accounts of how to do it. I tried a few, and all failed.

Eventually I found one that started with “forget all the difficult stuff you’ve read. Installing a LetsEncrypt ‘pem’ file into a Tomcat keyfile is easy. Here’s how…”. I followed that two-command process, and was immediately rewarded with full certificate security for my Tomcat application, WITHOUT having to create a browser exception for the certificate.

It is so very nice when something “just works” the way it’s supposed to work. It’s even nicer when you find simple, unambiguous instructions as a guide. Thanks to Maximilian Böhm and his guide here: https://maximilian-boehm.com/en-gb/blog/create-a-java-keystore-jks-from-lets-encrypt-certificates-1884000/