Search This Blog

Friday, May 4, 2018

A Free Public VDE (Virtual Distributed Ethernet) Switch: Connect anything to anything anywhere over layer-2 ethernet

The Public VDE Networking server at Università di Bologna does not seem to be up, so I deployed my own in the spirit of that original effort. It is open-access, public, available to everybody.

It allows any Virtual Distributed Ethernet (VDE) Switches anywhere to be connected securely over the internet.

To connect to my free open access VDE public ethernet network, just virtually "wire" your switch to my public one using this command:

dpipe vde_plug = ssh vde0@sanyalnet-cloud-vps3.freeddns.org vde_plug

I am using this VDE switch to connect a VAX-11/780 in Kitchener, Ontario, Canada to a bunch of DECnet nodes in the Washington DC metro area. The exact commands I am using to set up the local VDE switches and connect them via the public VDE switch are:

/usr/local/bin/vde_switch -t vde-decnet-tap0 -s /tmp/vde-decnet.ctl -m 666 --mgmt /tmp/vde-decnet.mgmt --mgmtmode 666 --daemon --fstp

/usr/local/bin/dpipe /usr/local/bin/vde_plug /tmp/vde-decnet.ctl = /usr/bin/ssh vde0@sanyalnet-cloud-vps3.freeddns.org vde_plug

The second command line runs in the foreground in the terminal unless you force it background using screen or nohup etc.

Also, the above command lines work on CentOS 7 on which I built VDE from sources. On Ubuntu, you can simply install vde2 from the repos which puts the tools in /usr/bin instead of /usr/local/bin.

If possible, please enable FSTP when you create your local VDE switches (use the --fstp parameter in the vde_switch command line) to try to control ethernet loopbacks and floods so that I don't have to keep rebooting my server.

Tuesday, May 1, 2018

How to create a Linux account with empty password (no password) with SSH access

I had a very good reason to want a password-less account for users to login over SSH: make a publicly available Virtual Distributed Ethernet (vde) tunnel broker for anyone to connect anything from anywhere over a free public globally available layer-2 virtual ethernet switch requiring no password (details in next post).

It turned out to be pretty tricky, but I finally have what I wanted - an account on a Ubuntu 14.04 server that accepts ssh connections from anywhere to a user without prompting from a password.  This has nothing to do with exporting rsa/dsa keys and manipulating .ssh/authorized_keys etc. Neither has this anything to do with passwordless logon to Linux graphical desktops.

Here is a summary of what worked for me.

  • adduser someuser
  • passwd -d someuser    #delete password
  • vi /etc/ssh/sshd_config
    • Chanege PermitEmptyPasswords from no to yes, i.e.
      # PermitEmptyPasswords no
      PermitEmptyPasswords yes
    • If AllowUsers is enabled, don't forget to add the new username to the list of allowed users. I always configure the AllowUsers line to limit usernames that can log in to my internet-facing servers.
  • service ssh restart
  • vi /etc/pam.d/common-auth
    • change nullok_secure to nullok as in:
      # auth    [success=1 default=ignore]      pam_unix.so nullok_secure
      auth    [success=1 default=ignore]      pam_unix.so nullok
  • vi /etc/securetty
    • add the following line (I put it under "console" at the very top):
      ssh
  • suppress the big Ubuntu login banner by creating an empty file called .hushlogin in the new user's home directory

--


Saturday, April 21, 2018

Fixing LED Turn Indicator Hyperflashing (Rapid Flashing with LED Replacement Bulbs): Ford F-150 SVT Raptor



I picked up LED 4057 turn indicator bulbs (white for parking/indicator front, red for tail/brake/indicator rear) for my 2012 Ford F-150 SVT Raptor. On putting them in, the turn signals started flashing too rapidly, like they do when a bulb is blown.

On researching this on the F-150 forums, I found this phenomenon is very well-known, and actually has a name: "hyperflashing". My Raptor apparently also does not have a real flasher; the flashing function is managed by one of the computers in the truck, the Body Control Module (BCM). The sound of the flasher from the dashboard is artificially generated.

The problem is with the extremely low power that LED lamps draw compared to incandescent lamps that the BCM is designed for. This makes the BCM think the bulbs are blown, and it switches to rapid flashing as a way to warn the driver that indicator lights are not working.

There are two solutions. The first solution is adding a resistor in parallel to the wiring to the LED bulbs, thus increasing the power load to fool the BCM into thinking it has working incandescent bulbs. The second solution is to reprogram the BCM to turn off the "failed bulb" feature so that the BCM does not hyperflash even though it thinks the bulbs are blown.

Being a software nerd, reprogramming the BCM obviously was my choice for the fix. Fortunately, thanks to a very enthusiastic Ford community, the configuration addresses and data values/parameters are available for the BCM and other computers in my Raptor in a fantastic spreadsheet available free online: "2011-2014 F-150 limited 4wd As-Built Options".

I first ordered a OHP Ford ELMconfig USB device 500kbit/s ELM327 compatible interface with MS-CAN switch for Forscan FoCCCus Mazda OBD2 diagnostics adapter. When it arrived, I plugged the USB connector to my Windows 10 laptop. Windows 10 was able to find a driver online which it installed automatically. The Windows 10 Device Manager then showed a new "USB Serial Port (COM3)" and a "USB Serial Converter" device.

Supratim Sanyal's Blog: Ford F-150 OBD-II (OBD2) USB Converter OHP HS-CAN MS-CAN Adapter Device Driver Windows 10
OHP OBD-II USB Adapter Device Driver on Windows 10

Supratim Sanyal's Blog: OHP ELMConfig OBD2 OBD-II USB Scanner Adapter Connected to PC
ohp ELMconfig OBD2 adapter connected to laptop

Supratim Sanyal's Blog: ohp ELMconfig OBD2 scanner USB adapter information card
OHP ELMconfig OBD2 USB adapter information card

Supratim Sanyal's Blog: OHP ELMconfig OBD-II Scanner USB Adapter connection to Windows 10 PC
OHP ELMconfig OBD-2 USB Adapter

With the OHP OBD-II-USB converter ready, I then went ahead to download FORScan - the free software that allows reconfiguration of the computers on-board the Ford F-150 (and other Ford vehicles) via reading and writing configurable register addresses documented in the "As-Built Options" spreadsheet.

I also downloaded the FORScan tutorial that has excellent step-by-step instructions on using FORScan.

Getting a "trial license" for FORScan turned out to be surprisingly easy. I signed up at the FORScan forum, and my account was approved within half an hour. Once approved, I obtained a trial license from http://forscan.org/forum/extlic.php using the Hardware ID available in FORScan application itself from the steering wheel icon with the yellow question mark at bottom left. This is exactly as described in the FORScan tutorial.

Supratim Sanyal's Blog: FORScan License Keygen generator
FORScan Trial License Generator


Supratim Sanyal's Blog: How to get FORScan Hardware ID Screen
FORScan Hardware ID Screen

Once the FORScan license file was loaded, I was all set to connect the ODB-II adapter to my truck and tweak the configuration of the Body Control Module computer.

Looking at the BCM tab of the , to fix hyperflashing of the front LED turn signal indicators, I needed to change the first value at addresses 726-13-01 from 0101 (Front lamp outage on (hyperflash)) to 0000 (Front Lamp Outage off). Similarly, to fix hyperflashing of the rear LED turn signal indicators, I needed to change the first value at address 726-14-01 from 0101 (stop/rear lamp outage on (hyperflash)) to 0000 (Stop/rear lamp outage off). This effectively disabled the hyperflash-if-bulb-blown logic, thus addressing the problem. Of course, this means that if any of the LED bulbs really blows, I wouldn't know about it without physically looking at those LED bulbs - but I can do that check manually once in a while and live with it.

Supratim Sanyal's Blog: 2011-2014 Ford F-150 Front and Rear Turn Indicator Hyperflashing Control Addresses on BCM (Body Control Module)


Follwing the FORScan tutorial, I connected the OHP ELMconfig adapter  to the ODB2 port under the steering wheel, connected the USB end to my laptop running FORScan, turned the key to ignition-on position (one step before starting the engine), and took a backup of the BCM configuration first.

Supratim Sanyal's Blog: ODB2 port on 2012 Ford F-150 SVT Raptor
ODB2 port on 2012 Ford F-150 SVT Raptor

Supratim Sanyal's Blog: OHP ODB2 USB Adapter connected to ODB2 port on Ford F-150 SVT Raptor
OHP ODB2 USB adapter connected to my 2012 Ford F-150 SVT Raptor

Then I went ahead and wrote 0000 to the two addresses, following on-screen instructions to turn my truck completely off and on each time.

And presto, the LED turn signal indicators do not hyperflash any more!

A backup of the files mentioned in this post is available at my google drive.






Friday, April 6, 2018

Tru64 Unix Tiny Web Server: nweb

Once I had Tru64 Unix 5.0 running on a FreeAXP AlphaServer 400, I went on a search for a very small but safe web server that would deliver one static html page to http clients.

My environment is Compaq C V6.1-011 on Digital UNIX V5.0 (Rev. 910) C compiler running on Tru64 Unix 5.0 (OSF1 V5.0 910 alpha).

The heavyweight Apache httpd was not in consideration - too much bloat for a single static page server.

I next attempted thttpd - tiny/turbo/throttling HTTP server. I had to comment out "typedef long long int64_t;" in mmc.c, thttpd.c and libhttpd.c because the compiler complained of prior declaration in /usr/include/sys/bitypes.h, and could build successfully. But, on attempting to execute it, I get:

/usr/local/sbin/thttpd: getaddrinfo (null) - servname not supported for ai_socktype

Unfortunately my emails to the subscription address for the thttpd mailing list as well as directly to the mailing list did not produce any response. It is very quiet in the thttpd world.

Finally, I struck gold with Nigel Griffiths' nweb: a tiny, safe Web server (static pages only) - a masterpiece in 200 lines of posix-compatible classic Unix-style C code. The only tweaks I made to version 23 of the C program are:

  • changed setpgrp() to setpgrp(0,0) for it to compile
  • changed the logger() function to log to Tru64's syslog facility instead of an ever-growing nweb.log log file
  • added a couple of mime types to the extensions array (ttf, css) for a downloadable font and CSS that my static page uses
  • brought inclusion of <sys/types.h> before <unistd.h> as recommended by Tru64 Unix man page for the setpgrp function
A simple "cc -o nweb23 nweb23.c" produced a working nweb23 executable (with just one warning about a usual signed vs unsigned int used as a reference) which I moved to /usr/local/sbin. I added a /sbin/init.d/nweb23 script:


#!/sbin/sh
#
# start nweb23 httpd web server daemon
#
PATH=/sbin:/usr/sbin:/usr/bin:/usr/local/sbin
PORT=80
WEBROOT=/usr/users/decnet/webroot
#
export PATH PORT WEBROOT
#
case "$1" in
'start')
                        echo "Starting nweb23 httpd web server daemon"
                        /usr/local/sbin/nweb23 $PORT $WEBROOT
                        ;;
*)
                        echo "Usage:  $0 {start}"
                        ;;
esac


and created a link under /sbin/rc3.d to the init script, i.e. S99nweb23 -> ../init.d/nweb23, to start nweb up at boot.

That is all it took. nweb is happily serving http requests from the Tru64 server at http://sanyal.duckdns.org:89/.

A tarball containing the modified nweb version 23 source code along with the Tru64 Unix binary can be downloaded from my google drive.

Thursday, March 29, 2018

Tru64 Unix: Bringing the legendary Digital UNIX (DEC OSF/1 AXP) Back to Life with DECnet, TCP/IP and LANMAN, NetBIOS, NetBEUI Networking

Supratim Sanyal's Blog: Tru64 Unix CDE (Common Desktop Environmrnt) login screen
Tru64 Unix CDE (Common Desktop Environment) login screen
Introducing the pioneering Tru64 Unix to my little network and having it talk to my various OpenVMS Alpha, OpenVMS VAX, Ultrix VAX, PDP-11/24 RSX-11M-PLUS, Windows NT 4.0, Windows XP, Power Macintosh G4 MacOS 9, Solaris 11 and Linux systems is so much fun!

Tru64 Unix was renamed from Digital Unix which itself was originally named DEC OSF/1 AXP. It is a complete and powerful commercial-grade 64-bit Unix operating system originally released for DEC Alpha processor. Like Apple's MaxOS X (and therefore also iOS, tvOS and watchOS), it is based on Carnegie Mellon University's Mach kernel. It illustrates the beauty of the micro-kernel architecture.

Unlike Digital's previous BSD-derived Ultrix, Tru64 is the root of a third Unix family by itself, in addition to BSD and System V.

The complete documentation set for Tru64 Unix is available online.

I installed Tru64 Unix 5.0 inside a 32-bit FreeAXP  2.6.1.560 instance emulating DEC AlphaServer 400 4/166 from the publicly available Tru64 Unix 5.0 installation CD ROMs. Like all of my DECnet nodes, I dedicated one network adapter to TCP/IP and Microsoft networking protocols (NetBIOS, NetBEUI), and another network adapter to DECnet.

Using a XDMCP remote Unix desktop session from MobaXterm, I could launch the Tru64 graphical desktop that is an implementation of Common Desktop Environment (CDE) - a collaborative effort of Sun, HP, IBM, DEC, SCO, Fujitsu and Hitachi. Interestingly, CDE is now also available as open-source.

Supratim Sanyal's blog: Tru64 Unix CDE Desktop Environment
Tru64 Unix CDE desktop
Finding DECnet-Plus for Tru64 UNIX V5.0 was a bit tricky, but with the help of a thriving DEC user community, I could install DECnet-Plus (DECnet OSI Phase V) for Tru64 Unix and connect to HECnet. It turns out there was no DECnet Phase IV stack ever released for Tru64 Unix 5.0, so I have to deal with mysterious (to me!) NCL commands instead of the familiar NCP.

A nifty script is included with DECnet for Tru64 that copies over entries in a node database from another DECnet node. It works even if the remote node is running DECnet Phase IV. I copied the HECnet node database from the HECnet node name database information service at MIM:: using:

# /usr/sbin/update_nodes -dlocal 1.13

To configure a public DECnet FAL (File Access Listener) service on Tru64 Unix, I first created a user "decnet" with home directory at /usr/users/decnet and dropped a text file "info.txt" into it. Then, using NCL, I enabled the FAL proxy and assigned the default user "decnet":

ncl> set session control application fal incoming proxy true
ncl> set session control application fal user name decnet

I then tested the Tru64's FAL service from MacOS 9 Pathworks for Macintosh successfully.

Supratim Sanyal's Blog: Tru64 Unix DECnet-Plus Phase V OSI file sharing over DECnet with MacOS 9 on Power Macintosh running Pathworks for Macintosh
Tru64 Unix file sharing over DECnet with MacOS 9 on Power Macintosh


I also tested Tru64's DECnet FAL service from a Windows XP system over DEC Pathworks 32 with success.

Supratim Sanyal's Blog: Decnet-Plus OSI Phase V for Tru64 Unix file sharing over DECnet with Windows XP DEC Pathworks 32
Tru64 Unix file sharing over DECnet with Windows XP


In addition to DECnet Plus OSI for Tru64 Unix, I installed the Advanced Server for Unix kit. This basically added Windows networking with Windows advanced server domain controller functionality to Tru64 Unix. Interestingly, it installed "NetBIOS over DECnet" on the DECnet NIC in addition to NetBIOS/NetBEUI on the TCP/IP NIC.

I configured Tru64 as the secondary domain controller. Sure enough, Tru64 shows up in the list of computers reachable over Windows networking from ENTEE4 which is a Windows NT 4.0 Server with TCP/IP and DECnet protocol support.

Supratim Sanyal's blog: Digital Compaq Tru64 Unix as Windows Network Domain Server LANMAN NetBIOS NetBEUI File and Printer Sharing
Tru64 Unix participating in Windows network as a secondary domain server

The usual DECnet-related commands like dcat, dcp, dlogin, dls etc. on Tru64 perform as expected and are similar to the DECnet commands on Ultrix. They were successful in communicating over DECnet with OpenVMS (VAX and Alpha), RSX-11M-PLUS, Windows NT, Windows XP, Windows for Workgroups 3.11, MacOS 9, Linux and Ultrix VAX nodes in my lab:

$ uname -a
OSF1 tru64.sanyalnet.lan V5.0 910 alpha
$
$ dls qcocal::info.txt          # OpenVMS VAX 7.3


Directory qcocal::DUA2:[FAL$SERVER]
INFO.TXT;22
$
$ dls juichi::info.txt          # PDP-11/24, RSX-11M-PLUS

Directory juichi::DB:[FALSERVER]
INFO.TXT;10
$
$ dls fedach::info.txt          # Linux Ubuntu 14

Directory fedach::
info.txt
$
$ dls ostara::info.txt          # DEC Ultrix 4

Directory ostara::/usr/users/guest/
info.txt
$
$ dls wexpee::info.txt          # Windows XP

Directory wexpee::C:\WINDOWS\system32\
info.txt
$
$ dls entee4::info.txt          # Windows NT 4.0

Directory entee4::C:\WINNT\system32\
info.txt
$
$ dls raptor::info.txt          # OpenVMS Alpha 8.3

Directory raptor::SYS$SPECIFIC:[FAL$SERVER]
INFO.TXT;8
$
$ dls wfw311::info.txt          # Windows for Workgroups 3.11

Directory wfw311::C:[DECNET]
INFO.TXT
$

I saved some of the installation sessions in log files for reference.

Tru64 Unix Installation Log



Tru64 Unix DECnet Networking Kit Installation Log

The following log captures installation of DECnet for Tru64 Unix 5.0 and successful login over DECnet to remote HECnet nodes BOPOHA and FRUGAL.



Tru64 Unix Advanced Server for Unix (Windows Network Integration) Kit Installation Log

This log captures installation of the Tru64 Unix Advanced Server for Unix package which allows Tru64 Unix to participate in a Windows network environment for seamless file and printer sharing, using Microsoft's NetBIOS and NetBEUI protocols over DECnet and TCP/IP.









Sunday, March 25, 2018

Stop Cron and Anacron job 'cron.daily' Family of emails

The standard solution to the cron daemon sending emails to root is:

  • For each cron job in crontab (accessed via "crontab -e"), redirect standard output and standard error to a file or to null, for example:
    0 5 * * 1 tar -zcf /var/backups/home.tgz /home >/dev/null 2>&1
  • Add the following to crontab before the cron jobs list:
    MAILTO=""
However, this still leaves Anacron to send emails with subject lines like "Anacron job 'cron.daily' on node foobar" every day, week and month. To get around this, edit /etc/anacrontab using your usual favorite editor and add MAILTO="" before the Anacron jobs list.

Here is an actual complete /etc/anacrontab:


# /etc/anacrontab: configuration file for anacron
# See anacron(8) and anacrontab(5) for details.

SHELL=/bin/sh
PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin
HOME=/root
LOGNAME=root
MAILTO=""

# These replace cron's entries
1       5       cron.daily      run-parts --report /etc/cron.daily
7       10      cron.weekly     run-parts --report /etc/cron.weekly
@monthly        15      cron.monthly    run-parts --report /etc/cron.monthly


This works on Ubuntu 14 and Ubuntu 17, and should work on all Anacron-enabled Unix and Linux systems.

Thursday, March 8, 2018

Teaching Windows XP to speak AppleTalk

Supratim Sanyal's Blog: AppleTalk protocol support on Windows XP
AppleTalk protocol support on Windows XP
Windows 2000, which I still consider Microsoft's zenith, shipped with native support for AppleTalk. This made it possible to seamlessly share files and printers between Macintoshes and Windows 2000 PCs over AppleTalk networks.

When Windows XP came along it was sadly missing AppleTalk protocol support - Microsoft had decided to take it out of the package. But discerning Windows users soon found a trick. One can simply copy over just six files from an existing Windows 2000 installation configured with AppleTalk into the Windows directory of XP. After copying over the six files and rebooting, XP offers AppleTalk as an additional protocol that can be installed on any network adapter.

This makes a nice addition to my little but diverse AppleTalk network consisting of MacOS 9 and Linux (via netatalk) by now letting Windows XP support AppleTalk printers. To connect an AppleTalk printer to Windows XP, use the usual "Add Printer" wizard from the "Printers and Faxes" control panel. You can create a new port for "AppleTalk Printing Devices" type of port.

Supratim Sanyal's Blog: Add AppleTalk Printer Port on Windows XP
Add AppleTalk Printer Port on Windows XP
Windows XP will go and look for connected AppleTalk printers and make them available. Unfortunately, this is where my test ends, since I do not have an AppleTalk printer to test with!

Supratim Sanyal's Blog: Connecting Windows XP to AppleTalk Printer
Connecting Windows XP to AppleTalk Printer

The six Windows 2000 files that provide AppleTalk support and can be copied from Windows 2000 to Windows XP are:
  1. C:\WINDOWS\INF\netatlk.inf
  2. C:\WINDOWS\SYSTEM32\sfmatmsg.dll
  3. C:\WINDOWS\SYSTEM32\sfmmon.dll
  4. C:\WINDOWS\SYSTEM32\sfmwshat.dll
  5. C:\WINDOWS\SYSTEM32\DRIVERS\sfmatalk.sys
  6. C:\WINDOWS\SYSTEM32\SPOOL\PRTPROCS\W32X86\sfmpsprt.dll

A copy of these six Windows 2000 AppleTalk files for Windows XP can be downloaded from my google drive. If you are more interested in Neko the mouse-chasing cat who lives on desktops, you can adopt Neko for your desktop from here.

Wednesday, January 17, 2018

The AppleTalk experience: Mac OS 9 on SheepShaver and Netatalk on Ubuntu (Classic Power Macintosh 9500 PowerPC G4)

Mac OS 9 running in SheepShaver accessing shared files on three Ubuntu nodes over AppleTalk via netatalk
Apple Mac OS 9 in SheepShaver communicating over AppleTalk network protocol with Ubuntu Linux nodes via Netatalk

With 10 DECnet nodes connected to the global hobbyist HECnet network stable and staying up, I started to wonder what other non-Internet Protocol (non-TCP/IP) networking experiment I could run. Apple's classic AppleTalk protocol came to mind.


Originally released as AppleNet in 1983 for the Apple II and Lisa, AppleTalk has roots in Xerox XNS. AppleTalk's ancestry is no less illustrious than DECnet.

Despite phenomenal rise of the Internet Protocol (TCP/IP), AppleTalk was supported all the way to the 2009 release of Mac OS X Snow Leopard. Interoperability with TCP/IP was introduced as far back as 1988 with MacTCP and later MacIP (Wikipedia) which basically piggybacked IP over AppleTalk. However, my objective here was to stay away from IP completely, and focus on pure AppleTalk.

I had zero experience with AppleTalk networking. Fortunately, there is still enough reading material out on the 'net to get a feel for it. "Inside Macintosh: Networking" is a great book. The Netatalk 2.0 documentation is fabulous. And Cisco's Protocol Filter appendix is handy in deciphering stuff like 0x809b ether-type packets that suddenly pop up in packet dumps once AppleTalk kicks in. 0x809b is EtherTalk, "an Apple AppleTalk networking protocol that enables AppleTalk to communicate over Ethernet cabling."

Supratim Sanyal's Blog: AppleTalk Protocol EtherTalk (ethertype 0x809b) frames captured by iptraf-ng packet capture tool
EtherTalk (ethertype 0x809b) frames captured by iptraf-ng on Ubuntu Linux

Objectives


After reading around a bit, and not being a AppleTalk expert, I set myself the simplest of objectives of this experiment:

  1. Bring up a classic Macintosh virtual machine running Mac OS with Ubuntu Linux as host
  2. Configure Mac OS and the virtual machine to support AppleTalk networking
  3. Add AppleTalk support to Ubuntu Linux host machine
  4. Have the Mac OS virtual machine access files on Ubuntu host machine via AppleTalk
  5. Bring in more Ubuntu Linux boxes supporting AppleTalk to the happy AppleTalk island
As the screenshot at the top of this post demonstrates, this experiment is pretty successful. In summary, the objectives were met respectively by:
  1. SheepShaver on Ubuntu running Mac OS 9, with sheep_net kernel network module
  2. The Mac OS 9 installation procedure installs AppleTalk
  3. Netatalk 2.0
    • Netatalk version 2.2.5 on Ubuntu 17
    • Netatalk version 2.2.2 on Ubuntu 14
  4. Editing configuration files of Netatalk daemons
  5. Same as 4
A note of caution: I had initially grabbed and built Netatalk 3.0 from source, but fell back to Netatalk 2.0 because support for AppleTalk was discarded in Netatalk 3.0.

Configuring SheepShaver to run a virtual Classic Apple Power Macintosh 9500 / PowerPC G4 CPU with MacOS 9 on Ubuntu Linux

Build SheepShaver from Source


There is some documentation here and here which boil down to the following. The Ubuntu version I built and run SheepShaver on is Ubuntu 17.04.

First, make sure the required packages are installed.

$ sudo apt-get install build-essential autoconf git libx11-dev libesd0-dev gtk+3.0-dev libsdl-dev libgtk+2.0-dev

Then, with root privileges, edit the file /etc/sysctl.conf to add the following lines at the bottom (this allows SheepShaver to run from a non-root account):

# --

# Needed for SheepShaver Mac Classic emulator
# --
vm.mmap_min_addr=0


Still with root privileges, enter the following command (or reboot):

service procps start


The following script fetches the SheepShaver source code and builds it.


I found various packages, all from standard Ubuntu repositories, to get a autoconfig result of:

SDL support ...................... : none
BINCUE support ................... : no
LIBVHD support ................... : no
FBDev DGA support ................ : yes
XFree86 DGA support .............. : yes
XFree86 VidMode support .......... : yes
Using PowerPC emulator ........... : yes
Enable JIT compiler .............. : yes
Enable video on SEGV signals ..... : yes
ESD sound support ................ : yes
GTK user interface ............... : gtk2
mon debugger support ............. : no
Addressing mode .................. : real
Bad memory access recovery type .. : siginfo

Once the main SheepShaver program has been built, the following script builds the sheep_net.ko kernel module.



The following script installs the sheep_net.ko kernel module and creates the /dev/sheep_net network device with the right ownership:



Configure and run SheepShaver


I created a directory ~/sheepshaver.run/ and copied over the SheepShaver binary from the build location (~/sheepshaver.build/macemu/SheepShaver/src/Unix/SheepShaver). I then looked around the internet to locate a "New World" ROM (newworld86.rom) and a Mac OS 9 bootable installer image (Mac OS 9.toast). There are pointers to where they can be obtained from at "Setting up SheepShaver for Mac OS X". I placed both these items in the same directory as the SheepShaver binary.

I created a subdirectory called "shared" to share files between the Ubuntu host and SheepShaver's Mac desktop. This directory is configured to be the "Unix Root" on SheepShaver and shows up as the drive "Unix" on the virtual Mac desktop. It simplifies transfer of files between Ubuntu host and Mac OS 9 virtual machines guest; anything copied into "shared" shows up in the "Unix" drive on Mac OS desktop though they cannot be executed directly from there, requiring me to copy executable installers from "Unix" to a local place on Mac OS first.

Finally I fired up SheepShaver, added the boot disk image, created two disk drives of 250 MB each, disabled sound (I do not want audio!), set the network interface and launched the emulated PowerMac G4. Here is a series of pictures of the options I configured in each tab:

Supratim Sanyal's Blog: SheepShaver Mac OS 9 Disk Configuration on Ubuntu Linux
SheepShaver Mac OS 9 Disk Volume and Shared Directory configuration

Supratim Sanyal's Blog: SheepShaver Mac OS 9 Graphics and Sound configuration Ubuntu Linux
SheepShaver Mac OS 9 Graphics and Sound configuration

Supratim Sanyal's Blog: SheepShaver Mac OS 9 Keyboard and Mouse configuration Ubuntu Linux
SheepShaver Mac OS 9 Keyboard and Mouse configuration

Supratim Sanyal's Blog: SheepShaver Mac OS 9 Serial Ports and Network Adapter configuration AppleTalk Ubuntu Linux
SheepShaver Mac OS 9 Serial Ports and Network Adapter configuration
I used a port on a VDE (Virtual Distributed Ethernet)  switch already configured and used by my DECnet nodes

Supratim Sanyal's Blog: SheepShaver Mac OS 9 Memory and Misc configuration Ubuntu Linux
SheepShaver Mac OS 9 Memory and Misc. configuration

Supratim Sanyal's Blog: Supratim Sanyal's Blog: SheepShaver Mac OS 9 JIT Compiler configuration Linux Ubuntu
SheepShaver Mac OS 9 JIT Compiler configuration


When the "Start" button is clicked, SheepShaver saves the configuration out to a dotted (hidden) text file called ".sheepshaver_prefs" in the home directory, i.e. "~/.sheepshaver_prefs". It then launches the virtual Power Macintosh and boots from the CD image.

On examining ~/.sheepshaver_prefs I found a time-saving trick - setting "nogui" to "true" does not launch the heavy graphical configuration tool first but boots up the Mac OS 9 virtual machine directly. It is much easier to directly edit ~/.sheepshaver_prefs instead of having to deal with a GUI. Here is my  ~/.sheepshaver_prefs:

disk SANYALnet-MacOS9-Disk1.dsk
disk SANYALnet-MacOS9-Disk2.dsk
extfs shared
screen win/800/600
windowmodes 0
screenmodes 0
seriala /dev/null
serialb /dev/null
rom newworld86.rom
bootdrive 0
bootdriver 0
ramsize 536870912
frameskip 12
gfxaccel false
nocdrom true
nonet false
nosound true
nogui true
noclipconversion false
ignoresegv true
ignoreillegal true
jit true
jit68k false
keyboardtype 5
ether vde-decnet-tap2
keycodes false
mousewheelmode 1
mousewheellines 3
dsp /dev/dsp
mixer /dev/mixer
ignoresegv true
idlewait true


I use the following script to start the Mac OS 9 SheepShaver application with the X11 GUI going to a detached virtual X11 display screen using the "xpra" tool.



Install Mac OS 9 in SheepShaver


Supratim Sanyal's Blog: Mac OS 9 booting up from CD ROM installer image in SheepShaver on Ubuntu Linux
Mac OS 9 Installation CD Boot in SheepShaver
As expected for new disks, the installer asks to initialize them. I decided to initialize the two disks with "Mac OS Extended" file system instead of the default "Mac OS Standard". It appears from the literature around the internet that "Mac OS Extended" is actually a journaling file system with better performance for normal use.

More importantly, the "Update Apple Hard Disk Drivers" checkbox in the "Options" screen accessible via the "Options..." button needs to be unchecked (cleared) for successful SheepShaver installation; SheepShaver hangs if this button is checked.

Supratim Sanyal's Blog: Mac OS 9 installation options: "Update Apple Hard Disk Drivers" must be unchecked for SheepShaver
Mac OS 9 installation options: "Update Apple Hard Disk Drivers" must be unchecked for SheepShaver
As far as "Customize" is concerned, I pretty much selected everything except Speech-related features.

Supratim Sanyal's Blog: Mac OS 9 Customized Installation Example: Selecting "All" Internet Access Features
Mac OS 9 Customized Installation Example: Selecting "All" Internet Access Features

I then proceeded with the installation by clicking "Start".

Supratim Sanyal's Blog: Mac OS 9 on SheepShaver CD ROM image installation progress
Mac OS 9 on SheepShaver CD ROM image installation progress

Once installation completed (it takes about 7 - 8 minutes), I shut Mac OS 9 down and restarted SheepShaver to get back to the launcher options GUI. I then removed the CD ROM from the list of volumes and booted up Mac OS 9 from the hard disk.

Supratim Sanyal's Blog: Mac OS 9 SheepShaver Configuration for Hard-Disk only volumes (CD ROM volume removed)
Mac OS 9 SheepShaver Configuration for Hard-Disk only volumes (CD ROM volume removed)
On booting up the first time after installation, Mac OS 9 presents a "Mac OS Setup Assistant" window. It is very important the Setup Assistant be not used; all configuration can be done separately using the various Control Panels reachable via the Apple logo at the top left. Mac OS Setup Assistant hangs SheepShaver, close it immediately!

Supratim Sanyal's Blog: Mac OS 9 Setup Assistant in SheepShaver for Ubuntu Linux
The Mac OS 9 Setup Assistant: Close the Setup Assistant immediately; it hangs SheepShaver
That completes the base installation of Mac OS 9 on SheepShaver, ready to be configured for its networking features. Here are a couple of more screenshots.

Supratim Sanyal's Blog: Clean initial installation of Mac OS 9 on Power Macintosh emulated by SheepShaver for Ubuntu Linux

Supratim Sanyal's Blog: Clean initial installation of Mac OS 9 on Power Macintosh emulated by SheepShaver for Ubuntu Linux
Clean initial installation of Mac OS 9 on Power Macintosh emulated by SheepShaver for Ubuntu Linux

Get Mac OS 9 in SheepShaver Ready for AppleTalk


It took me a while and many SheepShaver freezes to figure this out:

Mac OS 9 in SheepShaver needs to have an IP address, netmask and gateway configured, and the configured Gateway needs to be reachable, to not freeze and stay up even if we are using only AppleTalk.

It does not matter if the configured IP Gateway actually connects to the internet or anything at all; as long as Mac OS 9 can see it, it is happy.

I used the TCP/IP control panel to configure a dummy IP address, subnet mask, router (Apple speak for Gateway) and Name server (DNS).

Supratim Sanyal's Blog: Mac OS 9 TCP/IP configuration using TCP/IP Control Panel
TCP/IP Control Panel on Mac OS 9

Then I assigned the router and DNS address configured in Mac OS 9 to a different plug on the same VDE switch on the Ubuntu host so that Mac OS 9 can see the  IP gateway. There is no IP traffic after a few initial startup packets.

$ ip addr show vde-decnet-tap3
13: vde-decnet-tap3: <BROADCAST,MULTICAST,ALLMULTI,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UNKNOWN group default qlen 1000
    link/ether 82:29:cd:e3:f6:56 brd ff:ff:ff:ff:ff:ff
    inet 192.168.217.1/27 brd 192.168.217.31 scope global vde-decnet-tap3
       valid_lft forever preferred_lft forever

I did not have to do much else in terms of preparing for AppleTalk; it did really work "automagically" as claimed once Netatalk was configured on the Ubuntu host.

Install and Configure Netatalk on Linux Ubuntu


Unfortunately my total ignorance of AppleTalk resulted in spending significant time in numerous false starts before everything fell into place. One of the bigger mistakes I made was to download and build Netatalk 3.0 from source, only to realize later that they completely took out support for AppleTalk in Netatalk 3.0 onwards.

There is no AppleTalk router in my setup. All AppleTalk nodes are plugged into the same VDE virtual switch. Also, there is no AppleTalk Zone Name required or specified; there is only one zone which is also the default zone.

Ultimately what worked was a straight-forward installation from standard Ubuntu repository which pulled in Netatalk version 2.2.5 (on Ubuntu 17), and edits to just four files.

/etc/default/netatalk

To use the AFP file server, I enabled both the cnid_metad and afpd daemons. Since I am only interested in AppleTalk, I enabled the atalkd, papd and timelord "legacy" daemons but left the a2boot daemon disabled because I have no need for netbooting. Here is /etc/default/netatalk configuration file from MOKSHA which is the Ubuntu 17.04 host machine for SheepShaver.




/etc/netatalk/atalkd.conf

The virtual Ethernet card on my SheepShaver configuration is connected to a plug on a Virtual Distributed Ethernet (VDE) switch running on MOKSHA which also happens to host four more virtual machines that communicate over DECnet. All I needed to do with atalkd.conf is stick in the name of a hitherto unused VDE plug network device, just by itself, on the last line. Netatalk actually modifies this file on startup with a startup AppleTalk net-range and a self-generated node number (which it decides on "automagically" based on what it can see on the network) and adds those items to the configuration itself. Here is my atalkd.conf from MOKSHA after being modified by Netatalk.




/etc/netatalk/afpd.conf

This file configures file-sharing between Ubuntu and Mac OS 9 over AppleTalk. Interested only in AppleTalk, I disabled TCP and enabled DDP ("Datagram Delivery Protocol") that is part of the AppleTalk stack. I also enabled guest access requiring no authentication and a "welcome" message that is displayed when a guest connection is established to Ubuntu from Mac OS 9.

The Ubuntu directory made available publicly to Mac OS 9 over AppleTalk is actually configured in the next file.

Supratim Sanyal's Blog: AppleTalk Remote Network File Share Login Welcome Message on Mac OS 9 accessing Ubuntu shared directory
AppleTalk Network File Share Login Message


Here is my afpd.conf file.




/etc/netatalk/AppleVolumes.default

This file defines the directories to be shared by Ubuntu over AppleTalk for Mac OS clients. I configured just one directory to be shared with Mac OS. (I have a lofty goal of making this directory available over the FAL service of DECnet as well, hence the name). Here is my AppleVolumes.default configuration file.



Of course, the netatalk service has to restarted using the standard Ubuntu systemctl (or service on Ubuntu 14) tool for configuration changes to take effect. Also, netatalk has to be enabled for starting up at boot using systemctl (or update-rc.d on Ubuntu 14).


More AppleTalk Nodes


With the Ubuntu 17 host and SheepShaver Mac OS 9 communicating successfully over AppleTalk at this point, I added two more Ubuntu 14 nodes FEDACH and FOMFOR into the AppleTalk mix. They were already bridged into the DECnet VDE switch that I am using for AppleTalk too.

Once again I simply used Ubuntu's standard apt-get command to install Netatalk from the repos.

FEDACH, FOMFOR and MOKSHA have identical /etc/default/netatalk and /etc/netatalk/AppleVolumes.default configuration files.

The network adapter on FEDACH and FOMFOR dedicated to non-IP protocols (i.e. DECnet and AppleTalk only) is eth1. I accordingly updated /etc/netatalk/atalkd.conf with a single item "eth1" and restarted the netatalk service. As expected, Netatalk looked around, negotiated with other AppleTalk nodes and "automagically" filled in additional parameters with the same net ranges but unique node addresses as follows:

FEDACH - /etc/netatalk/atalkd.conf:
eth1 -phase 2 -net 0-65534 -addr 65280.225


FOMFOR - /etc/netatalk/atalkd.conf:
eth1 -phase 2 -net 0-65534 -addr 65280.149

I edited the /etc/netatalk/afpd.conf files on the two nodes to reflect the correct node names and login (welcome) messages:

FEDACH - /etc/netatalk/afpd.conf:
"FEDACH" -ddp -notcp -uamlist uams_guest.so -loginmesg "Welcome to FEDACH over AppleTalk, a SANYALnet Labs Ubuntu 14.04 server also speaking DECnet Phase IV and Internet Protocol (IP)."


FOMFOR - /etc/netatalk/afpd.conf:
"FOMFOR" -ddp -notcp -uamlist uams_guest.so -loginmesg "Welcome to FOMFOR over AppleTalk, a SANYALnet Labs Ubuntu 14.04 server also speaking DECnet Phase IV and Internet Protocol (IP)."


Continuing fun with Mac OS 9 Non-TCP/IP Networking Protocols

Power Macintosh 9500 / PowerPC G4 CPU / Mac OS 9 communicating over both AppleTalk and DECnet (no IP)

Moving on from AppleTalk, I went ahead to install DEC Pathworks for Macintosh and added DECnet support to Mac OS 9, thus having Mac OS 9 talking both AppleTalk and DECnet. But DECnet for Macintosh and Pathworks for Macintosh are the subjects of a separate post that I will get to some time! If it is up, you can see this Mac OS 9 virtual machine on HECnet.

Comments welcome.


Recommended Products from Amazon