Saturday, October 15, 2022

Landing Softly with Linux in 1992

From a young age, I have been in love with UNIX, having been exposed to it at my mother’s office. She used to take me with her to the office, when she went into the office, on the weekends. Being a geek, this was nirvana, as my mother was a publisher who worked for a major satellite communications corporation. So, they had almost every type of publishing and graphics related hardware and software that was available, in the 1980s. On one of my earliest visits, my mother left me in front of a Wang-made UNIX System V system, and started Colossal Cave Adventure (ADVENT) for me. I was immediately entranced, and played for hours. Later that afternoon I got my first taste of the shell when I managed to exit from the game.


After that first experience, I pined for my own UNIX workstation. However, being a kid born in the mid 1970s, the cost of such an endeavor was far too large for my own means, and would have to wait for the availability of a free UNIX system that would run on the limited IBM PC clone hardware that I had at my disposal. The Softlanding Linux System, or SLS, for short, was one of the first complete Linux distributions, and was first available in August in 1992. That availability gave me my chance, as I was informed of its release by an older friend who lived in Washington, DC. He even made for me a partial copy of the 3.5” floppy-based installation media, but unfortunately either the copy was damaged, incomplete, or I was too lacking in understanding to get it working. However, that attempt did strongly re-motivate me to get a complete system working.

SLS was available for download from the Internet, or on CD or floppy from the publisher, or most commonly, copied from someone else who had downloaded it. For my second installation attempt, I bought a new box of cheap white-label 3.5” floppy disks from Egghead Software, which was one of the local computer store chains in Maryland, where I grew up. I then took those floppies with me to my high school, where I volunteered in the library and computer programming labs, to image with the new copy of SLS that I downloaded using their (for the time) fast 1.5 Mbps Internet connection. Once I had all of the disk images downloaded, I started creating floppy disks from them. Of course, being inexperienced, I had no idea what disks I would actually need, and which I could skip, so I made them all. This amounted to 22 floppy disks, and this is where I ran into my first significant problem: cheap floppy disks were unreliable! I had no computer, at school, to test the installation on, so every time I wanted to try to replace bad floppy disks, I had to go to Egghead, exchange the failed disks, and return to my high school, on the other side of town. I didn’t have access to a car, so this was all on my bike. Thus, I could make (at most) one attempt per day. It took me several weeks to finally get a complete set of installation media!

Once I had a complete installation set, the real fun began. I can still remember my nervousness as I erased DOS from my 105MB Seagate (yeah, I’m a geek, and I remember the exact hardware that I used!) hard drive, to prepare for the Linux build. Hard drives were very expensive, and I could not afford a second drive, or to get one large enough to also install DOS on. As you might expect, my first installation did not succeed. If my memory is correct, I got all of the software loaded on the system, but the bootloader (the software that starts Linux, when the system is powered on) failed to function properly. I repeated the installation process over and over, until I got a very basic running system.

Folks who didn’t use early Linux probably wonder why I didn’t ask for help, or just look on the Internet for a detailed explanation of the process. In the early 90s, you couldn’t just sign up with an Internet Service Provider, and use your fancy new telephone modem (the predecessor to today’s cable modems) to make a phone connection to the ‘net. In order to have an Internet connection, at the time, one had to be a scientific or educational institution. Commercial access to the Internet didn’t come about until 1995, in any widespread manner. So, I didn’t have anyone to ask, or any easy source of information, since my high school didn’t subscribe to USENET, which is the predecessor to today’s online forums. Because of that lack, I had to complete the process using only the documentation present on the installation media, and trial and error.

With my newly completed base system, I next wanted to be able to use a graphical environment, and not just a text-based command line interface. The system that provided such an interface, at the time, is called the X Window System, and was created by MIT in 1984. There was a version created for PC-based UNIXes, like Linux, and 386/Free/NetBSD, called XFree86, in 1991. That system was included on the installation media for SLS, but it was very much a manual process to configure it. Not only did you need to know exactly what video hardware was in your system, but you had to manually specify the exact parameters of the video signal that you wanted your system to produce. To get the necessary information, you needed to have the instruction manual for your monitor and your video card. If you made an error in the video configuration, not only would you not get a functional graphical environment, you could actually damage your monitor. Given all of this, and the fact that I, like many other computer users of the time, did not buy my monitor or video card new, it took me several weeks to get the X Window System properly configured.

Once the system was up and running, with the graphical user interface functional, I proceeded towards the last obstacle: customizing the Linux kernel. With modern operating systems, including Linux, you no longer have to build your own kernel, but with all UNIX variants until the mid 1990s, kernel compiling was required to add support for your specific hardware configuration. For example, if you wanted to add support for a sound card, like a Sound Blaster, Adlib, or Pro Audio Spectrum, you needed to build a custom kernel. Building the kernel was a mostly straightforward procedure, with one exception: you had to know exactly what hardware was in your system, and how it was configured. There was a large list of yes/no questions that had to be answered correctly, and once complete you could install the new kernel. If you made any errors, the new kernel would fail to boot the system, and you would have to fall back on the previous one (assuming that you hadn’t replaced it!).

With all of these caveats, and the clear complexity, you might well ask yourself why anyone would attempt to install and run Linux, in 1992. The answer varied by the individual, but for me, it gave access to the advanced tools and efficiency of a UNIX system, on PC hardware that were within my budget. All of the difficulties were just part of the journey.

Tuesday, September 20, 2022

Setting Apple Keyboards to Default to Function Keys, Instead of Media Keys

This is just a quick post, but many of y'all may have run into the same issue that I have; that Apple devices default to sending media actions (volume up/down, key backlight, screen brightness, etc.) instead of the normal function key (F1, F2, etc.).

TLDR:

$ echo options hid_apple fnmode=0 | sudo tee -a /etc/modprobe.d/hid_apple.conf

This sets the system to send the scan code for the function key by default, and to send the media action if you press the Fn key, along with the function key.

Friday, December 31, 2021

Setting Up a Networked SunOS 4.1.4 VM in qemu

If you're only interested in the implementation, skip ahead to SETUP.

A Little History

I started my UNIX career at the US National Institutes of Health (NIH). When I first started there, in 1992, I was a student intern with the Office of the Director. I returned, as a student assistant computer specialist, in 1995. At that time, I was given access to an amazing variety of state of the art equipment, including a pair of Sun SPARCstation 2s and a SPARCstation 10, which were exclusively for my use. Given the time period, I installed Solaris 2.x on them, starting with release 2.5. There were still machines around, mostly SS1, SS1+, and SS2 models, running SunOS 4.x, but I didn't have much interaction with them. They were mostly AFS (Andrew file system, an early distributed filesystem standard, created by Carnegie Mellon University) hosts, and were old tech, to me. So, while I saw fellow employees using them, I didn't pay a lot of attention to how they worked.

Interest Surfaces

I have always had an interest in what would be considered vintage equipment, since I didn't have the means to purchase state of the art machines. The first UNIX box that I personally owned was a DECstation 5000/120 that I purchased from Terrapin Trader, the surplus sales group at the University of Maryland, College Park. That machine didn't come with a complete operating system, so I quickly located The NetBSD Project, and the nascent pmax port, just before its first release, in NetBSD 1.1. I did some basic testing, and got my system working around November of 1997. This was my first real interaction with BSD UNIX, in any form. I quickly came to appreciate the extremely open and collaborative nature of NetBSD, and have enjoyed it, in many forms, from then until now. My interest in NetBSD led to investigations into the history of BSD, in general, and to my presentation on "Unusual UNIXes" at the Vintage Computer Festival East 2019.

Setup

So, let's get rolling with some actual shell! To get started, you should make sure that you have qemu built for your system. Here are some links to get you started:

I use qemu on a ton of platforms, but as I type this, I'm on vacation, so I am currently using an Apple MacBook Air (2020/M1). So, I built qemu (with GL acceleration), following the instructions from knazarov's homebrew-qemu-virgl repo. Once I had that running, I created a new folder to store my SPARCstation 5 VM in, and grabbed the necessary components:

$ mkdir sunos-414-sparc
$ cd sunos-414-sparc
$ wget https://fsck.technology/software/Sun%20Microsystems/SunOS%20Install%20Media/SunOS%204.1.4%20SPARC%20%28CD%29/sunos_4.1.4_install.iso
$ wget https://github.com/itomato/NeXTSPARC/raw/master/ROMs/SPARC/ss5.bin

Once I had those, I started the configuration of the VM. Let me first thank KEKLKAKL, who provided a great starting point for this exercise. To get started, I generated the disk that I would be installing SunOS 4.1.4 on, and created my launch script:

$ qemu-img create -f qcow2 -o compat=1.1 sunos414.img 2G
$ cat << EOF > run.sh
> #!/bin/bash
qemu-system-sparc -L . \
-bios ss5.bin \
-m 32 \
-M SS-5 \
-drive file=sunos414.img,format=qcow2,media=disk \
-drive file=sunos_4.1.4_install.iso,format=raw,media=cdrom \
-net nic \
-net user,net=192.168.76.0/24,hostfwd=tcp::2222-:22
> EOF

Notice that I have changed the default network range that qemu provides for user (SLIRP) networking. I did this because I was having issues in getting SunOS to set the netmask correctly for qemu's default 10.0.2.0/24 subnet. I then launched the installation, using ./run.sh, and followed KEKLKAKI's excellent walk-through of the installation of SunOS 4.1.4. During the installation, I chose 192.168.76.15 as the IP address for the VM.

Once that was complete, I rebooted the system, and configured the default gateway. This is a little more difficult than it is in Solaris 2.x/SunOS 5.x, as there is no /etc/defaultrouter file. Instead, we add the following to /etc/rc.local:

$ echo "route add net 0.0.0.0 192.168.76.2 1" >> /etc/rc.local

This adds a default route (0.0.0.0 network) with 192.168.76.2 as the gateway and a metric of 1, since there is one hop to that gateway.

DNS on SunOS 4.1.4

By default, SunOS 4.x does not do DNS, except as a fall-back from NIS. Yes, Sun really wanted everyone to get onboard with NIS, and even expected you to use it for TCP/IP name resolution. So, your options are:

  1. install a NIS/YP server as a DNS proxy
  2. do some library hacking to change the resolution priorities

I chose to do #2, as that sounded a lot more straight-forward. Sun actually wrote up a great document on how to do just that, and I have captured it here. I created the resolv.conf as follows:

 $ echo "nameserver 192.168.76.3" > /etc/resolv.conf

Once you do that, you have a working emulated SPARCstation 5, running SunOS 4.1.4, with functional TCP/IP!


Monday, September 6, 2021

Installing a Real SSL Certificate on a UniFi Cloud Key

 I recently decided that I was no longer going to tolerate my UniFi Cloud Key's web management tool using a self-signed SSL certificate. I have, many times in the past, replaced the supplied certificates on the self-installed UniFi Controller software that I have run, on various Raspberry Pis or Linux VMs. The process has never been all that cumbersome, and it involved updating the `keystore.jks` file, and restarting the UniFi Controller.

However, the process seems to be very different, on the Cloud Key Gen 2. I'm not sure if the same goes for the Gen 1 Cloud Key, but it seems likely, as UniFi tends to update the software on all devices, with each release. I'd have no problem with this, but the process is completely undocumented.

After many, many hours of poking and prodding my Cloud Key, and much searching of the UniFi Community forum, I found the following fantastic post, from the user loafbread:

https://community.ui.com/questions/Install-a-Commercial-Wildcard-SSL-Certificate-on-Cloud-Key-and-Controller/040c640e-5c48-4477-82dd-aff56178d3f3#answer/b3bb7541-51d0-432a-a33b-b9864615604d

So, it seems that Ubiquiti has made the SSL certificate process much easier. Fantastic, of course, but they somehow failed to document that fact. To make sure that this critical bit of information is maintained, I will summarize the process, here:

  1. copy your PEM-format certificates to your Cloud Key
    1. you will need both the certificate itself and the full CA chain certificate files
  2. back up the following files:
    1. cp -p /data/unifi-core/config/unifi-core.crt /data/unifi-core/config/unifi-core.crt.orig
    2. cp -p /data/unifi-core/config/unifi-core.key /data/unifi-core/config/unifi-core.key.orig
  3. replace the the unifi-core.crt file with your full CA certificate chain and the unifi-core.key file with your certificate
  4. restart the unifi-core service
    1. systemctl restart unifi-core.service

So, the process isn't difficult, if it were only documented.

Oh well.

Monday, January 18, 2021

Building Python 3.9.1 for Solaris 10

 I won’t get into the whys or the wherefores, but I needed to build Python 3.9.1 for Solaris 10, using gcc-5.5. I attempted the build, using the guide found here, but ran into an issue with setup.py, preventing the building of the socket module.

To get past this, I patched setup.py, with the patch I posted here.

I then used the following configure line, to set up the build:

$ ./configure --prefix=/opt/python3 --with-openssl=/opt/csw/ --enable-optimizations LDFLAGS='-L/opt/local/lib -I/opt/csw/include/ncurses -I/opt/csw/include -L/opt/csw/lib  -R/opt/local/lib' PKG_CONFIG_PATH=/opt/csw/lib/amd64/pkgconfig/ CPPFLAGS='-L/opt/local/lib -I/opt/csw/include -I/opt/csw/include/ncurses -L/opt/csw/lib  -R/opt/local/lib'

After that, everything worked fine.

Friday, December 18, 2020

Samba and Windows 98

 I've got a Windows 98 host here (yes, really, in 2020!) that I use to read and write floppy disks for my various vintage systems. For those who are curious, it is (at the moment):

Compaq Deskpro EN (chassis only)
Gigabyte GA-6VEM Socket 370 mainboard
Pentium 3 1.4 GHz
1 GB RAM
60 GB SATA2 SSD with IDE/SATA bridge
1.44 MB and 360 kB floppy drives

 I was having issues with the machine being unable to connect to my Fedora-based NAS, receiving the error:

The solution was suggested here, but I needed to add one more configuration item:

[global]
server min protocol = NT1
lanman auth = yes
ntlm auth = yes

That solved the problem and allowed my 98 host to connect and mount my shares. Of course, enabling LANMAN auth is a significant security hole, but on my internal network, I'm not too worried.


Friday, December 6, 2019

Beta Testing the Engravinator, Part 2

Just a quick update on the Engravinator...I completed printing the parts to build, early this morning, and I was really happy with how they came out:


A lot of that goes down to how Adam (the creator) laid these parts out, for printing.  For those who are unaware, the orientation of a part on the build plate, has a lot to do with how strong it is, under torsion, compression, tension, and shear on the X, Y, and Z axes.  This is especially a b.g deal, due to the additive nature of the plastic 3D printing process.

I also assembled the aluminum extrusion frame of the engraver.  Again, I can't say enough positive about the quality of the kit, and the thoughtfulness of the engineering.  Instead of the usual hammer nuts, or t-nuts, Adam included sprung post-insertion nuts, which can be added after assembly of the extrusions, and also don't slide around, or fall out, when you rotate the item being built.  These cost a bit more, but are really helpful!

Here is the completed frame, which is as far as I have completed, so far:


I'll continue to post here, as I build the kit, and give my thoughts on it.