Sunday, October 27, 2013

SCO OpenServer 5.0.5

Introduction

It seems like everybody hates SCO these days. But, there was a time... Way back, when they did good work, or at least work that enabled me to do good work. My understanding of SCO's history is a little fuzzy, but as I remember it, they spun off of Microsoft when Microsoft decided not to pursue Xenix. Either that or they bought Xenix from Microsoft. Something like that. Then they went on to develop a full fledged Unix for x86 and owned that market until Linux matured. In the mid-to-late 90's, Caldera began to challenge them with their Linux offering. SCO's technology lagged but they had a huge customer base. Eventually SCO proper got out of the OS business, changed their name to Tarantella and went on to continue development and support of their Tarantella platform. Caldera basically bought their customer base and ended up with their OS development business in the deal. Then leadership changed at Caldera. Caldera renamed themselves The SCO Group to capitalize on the name equity and began suing people left and right. That didn't go so well for them and I'm not exactly sure what happened next. They either renamed themselves Xinuos or Xinuos bought them, or something.

At any rate, before all of the politics, when I was a kid, my Dad used to run companies off of a PC, SCO Xenix (and later Unix), a Computone Intelliport (or later Intelliserver), and several dozen Wyse terminals. When I grew up, I wrote more software for those systems than I can even begin to remember.

Those were the days.

For a while, SCO Unix was pretty awesome too. When OpenServer came out in the early 90's, it had shared object libraries, a journaling filesystem, a Motif-based graphical desktop, graphical system administration tools, drivers written by the hardware vendors themselves and back-compatibility all the way to Xenix 286. Linux was still using coff binaries, libc4, ext2, athena widgets and you had to be really careful what hardware you tried to run it on. For a while, you could buy a single-user development version of OpenServer for like $100 too. I continued to use SCO, basically until the Linux distros started including ext3 and Gnome.

Between development versions and swag from old companies, my Dad and I ended up with several versions of SCO Unix and Xenix and software that ran on them. We used them for a while but for years now, the CD's and license keys have been sitting in boxes, collecting dust. He recently dug through all that though and came up with a copy of OpenServer 5.0.5, circa 1999.

5.0.4 and 5.0.5 were both very popular versions of OpenServer. Earlier versions were buggy and though later versions added DHCP and USB support, those features just weren't all that important on the server. Later versions suffered from competition with UnixWare, Solaris x86 and Linux too, and from general anti-SCO sentiment.

Installation

The first challenge with any of these older OS'es is finding an emulator that will actually boot them. Fortunately SCO OSR 5 is semi-supported by VMware. For a while, it was even one of the OS'es you could select from the OS list during installation.

I used an 8g disk and 128m of RAM, which I believe were the defaults and selected Other from the OS list.

The CD wasn't bootable though. Instead I had to mount it, find the boot disk image at images/boot/install.img and copy it out. The bootloader loaded fine but there is a trick to getting it the installer to actually run. I'm not sure where I found the trick, but I had it in some notes from the last OSR 5.0.5 install I did, umpteen years ago. Basically it needs a contiguous block of at least 32M of RAM, probably to load a ramdisk into.

The magic bootstring:

defbootstr mem=1m-64m

That actually allocates 63m of contiguous RAM. I might have gotten away with a 1m-33m parameter but 1m-64m was in my notes, so I used that.

OSR 5.0.5 - 1 boot

Apparently (according to my old notes), 8g drives are supported by default but if you want to use a drive larger than 8g then you have to add a biosgeom=(cylinders,heads,sectors) flag as well. cylinders=(#ofgig*1024*1024/63/255*2)-5. So, for a 30g disk, (30*1024*1024/63/255*2)-5=3911. You'd use:

defbootstr mem=1m-64m biosgeom=(3911,255,63)

Ha, I actually remember having to upgrade the bios in many of my old computers to support disks larger than 8g.

Anyway, after supplying the proper boot string, the installer started up.

I always thought the installer was attractive, as text-based installers go anyway.

It is a little quirky. You use arrows to move around, enter to accept an options and space to change an option. The cdrom drive isn't auto-detected, you have to specify whether it's on the primary or secondary bus and whether it's the master or slave. The "System name" prompt wants the host name. You can mostly accept the defaults.

One thing I always did though is turn off Bad Tracking, otherwise the installer will scan the drive and look for bad sectors. This takes eons and isn't necessary. Another quirk in the installer though... After turning Bad Tracking off, the installer still reports that its still on. It's not. There's just a bug in the installer.

OpenServer 5.0.5 doesn't support DHCP so you have to give it an IP address. It does support the emulated PCNet card though.

For video and graphics, use VESA SVGA (the default).

Oddly, the mouse is not configured by default and must be set to "Low Resolution Keyboard Mouse".

After all that, and otherwise accepting defaults, the installer will run unattended.

OSR 5.0.5 - 2 install

And when it's done, after a reboot, you get a fairly attractive graphical login.

OSR 5.0.5 - 3 first login

At one of the companies I used to work for, we named our servers after scientists. We'd swap that SCO logo for a photo of them and set the background to something appropriate as well. It was loads of fun.

Logging in revealed the Motif-based desktop.

OSR 5.0.5 - 4 desktop

State of the art for when it was released in 1995. Actually, I that's when I first saw it, in OpenServer 5.0.0. SCO released their OpenDesktop product back in 1990. It's possible that it came with the same desktop. I'm not sure.

A Post-Install Tweaks

Post-installation, as usual, I had to tweak a few things.

First, I created a user for myself with:

useradd -m

Next, I disabled the graphical login and I wouldn't be needing it in the future.

scologin stop scologin disable

Then I finished the network setup. The installer prompts for an IP address, netmask, hostname and domain name but fails to prompt for a gateway and DNS information.

Setting up DNS is straightforward. Create /etc/resolv.conf with something like:

domain firstworks.com nameserver 192.168.123.37

Adding a gateway is less straightforward. I remember from setting up 5.0.2 (Internet FastStart) that there is some file, somewhere in the system, that if you put the IP address of the gateway in it, it will automatically be set at boot. It's not in an intuitive place though and I had an impossible time finding it. For all I know, it only worked on 5.0.2. What we always did was edit /etc/tcp and look for a line like:

/etc/route add 244.0.0.0 192.168.123.46 0 > /dev/null 2>&1

Then add a line after it like:

/etc/route add default 192.168.123.254 > /dev/null 2>&1

So that's what I did. After a reboot, I had networking.

I also fixed the man page system.

A little digressive background on the OpenServer man page system...

In OpenServer, man pages are actually served by a small http server called scohttpd. In theory, this is a really cool idea.

First, you can read the man pages by pointing a browser at port 457 and drilling down. However, if you want to crash a modern browser, go ahead and try that. The man pages are compressed with the "compress" format (which predates gzip) and apparently modern browsers think they can handle that and then die trying.

Second, you could install all the man pages on a "man server" and point the other systems at it using the MANPORT and MANSERVER environment variables rather than having to install man pages on every system in the network. In the late 90's this would have saved an appreciable amount of disk space. SCO software packages are even structured to make this possible. SCO never promoted doing this though, for some reason, and sadly, the feature went largely unused.

The man system has a bug though. The scohttpd server runs early in the boot process and some time later in the boot process, the socket files that it uses get deleted.

A quick fix is to edit /etc/rc and append:

/etc/scohttp stop /etc/scohttp start

...and reboot.

OSR 5.0.5 - 5 text login

Woohoo! Text login and working man pages.

Next, I installed the SCO OpenServer Development System and SCO Optimizing C Compiler from the distribution CD.

SCO's package manager is an interactive program called "custom". As in, to "customize" your system.

It, along with the rest of the system-administration tools, is written in TCL and, depending on whether you're running in a graphical environment or not, displays a graphical or text-based UI. The UI's look very similar and function identically. I was always impresssed with that technology.

To install the dev tools, I ran custom and selected Software->Install New->From osr505 (the name of my system)->CD-ROM Drive 0. I unselected Microsoft Client Software, selected SCO OpenServer Development System and SCO Optimizing C Compiler and selected Install.

If I may digress again...

Another very cool feature of OpenServer is the "From osr505" option that I mentioned above. CD-ROM drives in the late 90's were still really, really slow. If you had a software package installed on another system in the network, instead of installing from a CD on the local machine, you could tell custom to install it from another machine, across the network. The packages were structured to keep the original copy of config files too, so if you did a network install from another machine, you wouldn't get a modified version of the config files. With fast internet, apt-get, yum and friends, this approach is obsolete these days, but in the 90's, it was awesome.

Every OpenServer release was followed up with a bunch of patches and ultimately a release supplement roll up. Sometimes there were several consecutive Release Supplements. Patches and Release Supplements are all listed at http://www.sco.com/support/ftplists/osr5list.html and available directly at ftp://ftp.sco.com/pub/openserver5/. I installed RS505A, which patched the OS and the Development System.

SCO packages are quirky. They are typically distrbuted as a tar or cpio file containing a set of files named VOL.000.000, VOL.001.000, VOL.002.000, etc. which are themselves, cpio files containing the software. To install them, you must extract the file, tell custom to install "Media Images" and point it at the directory containing the VOL files. I think there is a non-interactive way to use custom, but I never figured it out. I don't think there's any way to get it to dig into a tar or cpio file though. So, package installation has always been a manually intensive process.

I didn't at this point, but if you attempt an OpenServer installation, I recommend installing the oss646b supplement as well, to save yourself lots of headaches later. Ironically, it's missing from the list of supplements, but it's absolutely critical if you want to use gcc rather than the native C compiler. It's available at ftp://ftp.sco.com/pub/openserver5/oss646b/.

Remote Access

Telnet and ftp are the only built-in way to access an OSR 5.0.5 machine but ssh is available via "Skunkware".

Over the years, SCO downloaded, patched, compiled and made installable packages for a bunch of open source software. They called this project Skunkware, an allusion to Lockheed Skunkworks, I guess. These packages are available at ftp://ftp2.sco.com/pub/skunkware and they put out "Skunkware" CD's too. Apparently they'd been doing this since the Xenix days, but I'm not sure how they distributed the software back then.

Skunkware packages for OSR5 in particular are available at ftp://ftp2.sco.com/pub/skunkware/osr5/vols. The openssh package is among them.

Actually, I had to install zlib, prngd and openssh. I also had to tweak /etc/init.d/RMTMPFILES and add:

rm -f /usr/local/var/prngd/prngd.lock

Otherwise prngd would leave a lock file lying around and wouldn't restart after a reboot.

I tried to get X11 forwarding working. In /usr/local/etc/sshd_config, I uncommented and set:

X11Forwarding yes

I eventually discovered that the path to xauth was hardcoded into the program too, at /usr/X11R6/bin, which doesn't exist on OSR5 as OSR5's X Windows is based on X11R5, not X11R6.

I made the appropriate directories and added a symlink:

mkdir /usr/X11R6
mkdir /usr/X11R6/bin
cd /usr/X11R6/bin
ln -s /opt/K/SCO/XServer/5.2.2a/usr/bin/X11/xauth xauth

Unfortunately, X11 forwarding still failed with "X11 connection rejected because of wrong authentication." I still haven't figured it out. It's possible that xauth from X11R5 just isn't compatible with modern X. X11R6 is available for OSR5. Maybe I'll try that some day.

What's up with that crazy path to xauth?

Another fairly innovative thing that SCO did with the OpenServer series is install literally everything under /opt and /var/opt and create symlinks from the files there into /bin, /lib, /usr/bin, /usr/lib, /etc and so forth.

Internally, their package manager would just extract a new package into /opt and /var/opt and run the "fixmog" program to update the links.

Patch management was easy for the installer too. The patch was installed under /opt and /var/opt and making the patch available just involved updating the links. Rolling the patch back was simple too. Remove the patch, update the links.

The real power of this approach though, SCO never promoted. You could install software on one machine, NFS-export the directories for that package under /opt and /var/opt, mount them on another machine and run fixmog on that machine. The software was then immediately available on the other machine without having to fiddle with PATH's or LD_LIBRARY_PATH's. We did this a lot. It was quirky though, in that the packages showed in custom as having been installed locally, and if you didn't know they were NFS-distributed and deleted one, it would delete it from the app server. Maybe I can see why SCO never promoted NFS-exporting their software.

The whole links-everywhere thing seemed like a good idea, but it turned out to be confusing as hell. The output of "ls -l" had a gazillion symlinks to long paths and looked terribly cluttered. Just running "l" appended a @ to the filename if it was a link, which was also confusing. I think there were issues with scripts that ran ls -l or l as well. In the end, the dpkg/rpm approach was superior.

But I digress...

With OpenSSH installed, I could ssh into the VM. Yay, no more working on the console.

I could also scp and sftp.

Compression

Sadly, OSR505 comes with compress/uncompress but doesn't come with gzip, bzip2, zip or unzip and its tar program lacks the ability to uncompress on the fly. Fortunately GNU tar and the rest of those programs are available via Skunkware as well.

Web

OSR505 comes with Netscape Communicator 4.05 which had a laughably difficult time rendering anything. I was able to install lynx and wget from Skunkware. Maybe someday I'll work on getting a semi-modern graphical browser working.

On the server side, 5.0.5 comes with the Netscape FastTrack Server. I bet you didn't even know Netscape made a web server. They did. I used it for years and years.

If you run a "ps -efa | grep http" on a running OSR505 system, it will reveal a confusing array of web servers, actually:

    root   544     1  0   Oct-18       ?    00:00:00 /var/scohttp/scohttpd -d /var/scohttp
  nouser   467   466  0   Oct-18       ?    00:00:00 /usr/internet/etc/ncsa_httpd -d /usr/internet/admin
    root   411     1  0   Oct-18       ?    00:00:00 /usr/internet/ns_httpd/admserv/ns-admin -d /usr/internet/ns_httpd/admserv
    root   413   411  0   Oct-18       ?    00:00:00 /usr/internet/ns_httpd/admserv/ns-admin -d /usr/internet/ns_httpd/admserv
    root   415   413  0   Oct-18       ?    00:00:00 /usr/internet/ns_httpd/admserv/ns-admin -d /usr/internet/ns_httpd/admserv
  nouser   420     1  0   Oct-18       ?    00:00:00 ./ns-httpd -d /usr/internet/ns_httpd/httpd-80/config
    root   466     1  0   Oct-18       ?    00:00:00 /usr/internet/etc/ncsa_httpd -d /usr/internet/admin
  nouser   421   420  0   Oct-18       ?    00:00:00 ./ns-httpd -d /usr/internet/ns_httpd/httpd-80/config

What the heck?

The ns-httpd processes are the Netscape FastTrack server - the web-server proper. The scohttpd server is for serving man pages. The ns-admin servers run a web-based configuration interface for the Netscape FastTrack server. The ncsa_httpd process runs a web-based configuration interface for configuring networking and other things on the local system (very quirky). If you enable secure httpd on the FastTrack server, a second set of FastTrack servers will start up and a second set of servers will start up for administering it. Gazillions of web servers on an OSR5 system. They used them for everything.

I aimed a browser at the various servers to verify that they were working but I didn't play with them other than that. Maybe later.

Development

Yes. This is what I'm always really up to.

The native compiler had a hilariously difficult time making sense of my software. Maybe one day I'll tweak it to work with the native toolchain, but I figured I'd have an easier time with gcc.

In retrospect, it might have been easier to modify my software.

Several different versions of gcc are available via Skunkware and one via a "GNU Tools Supplement" available at ftp://ftp.sco.com/pub/openserver6/opensrc/gnutools-5.0.7Kj. None of them worked. This seemed strange because I know confidently that I used gcc for years on various OSR 5.0.X platforms.

It took hours and hours of installing, uninstalling, patching and rolling back to figure out how to get everything working but here's a summary of the challenges and solutions:

  • The linker ld, as shipped by default and updated by RS505A doesn't support -static or -R options but libtool insists that it does.
    • The -static issue expresses itself with lots of "relocations remaining" errors at link time.
    • Actually ld does support -R but it means something totally different than libtool thinks it does, it's not the rpath.
  • oss499a adds -static support (or somehow works around it) but occasionally "relocations remaining" errors persist.
  • oss646b fixes all of these issues but causes the Skunkware gcc's to error out at link time with a _fini error.
  • The gcc from gnutools fixes the _fini error.
  • So, you have to use oss646b and gcc from gnutools, there's no other reliable option.

I didn't install all of gnutools, only GCC. Some of the other packages are duplicates (or newer versions of) tools I'd already installed and some of them require a different package called gwxlibs. In fact, during intallation it warns about:

Some of the selected software depends on other software that is not currently installed on your system.

...but it's safe to ignore the warning if you're just installing gcc.

I also installed perl, python, php4, pth (a portable pthreads package required by python), readline, bash, cvs and gmake from Skunkware. I'd swear that Java 1.1.3 was once available for OSR5 too, and there are even allusions to this on the SCO site but I can't find it anywhere anymore.

I tried installing openssl and postgresql from Skunkware but as it turns out, openssl only provides static libraries and postgresql requires the FSU-pthreads package which causes relocation errors at runtime.

I could probably build openssl from source and maybe postgresql too, against pth, but I'll save that for another day.

After all that, and a few tweaks to my code, I was eventually able to build and install everything. The SQL Relay installation was a little anticlimactic because I didn't have any database software installed to run the server against, but the client ran fine.

$ uname -a
SCO_SV osr505 3.2 5.0.5 i386
$ sqlrsh -host fedora19 -port 9000 -user test -password test
SQLRShell - Version 0.53
        Connected to: fedora19:9000 as test

        type help; for help.

0> select banner from sys.v_$version;
BANNER
============================================================================
Oracle Database 12c Enterprise Edition Release 12.1.0.1.0 - 64bit Production
PL/SQL Release 12.1.0.1.0 - Production
CORE    12.1.0.1.0      Production                                              
TNS for Linux: Version 12.1.0.1.0 - Production
NLSRTL Version 12.1.0.1.0 - Production
        Rows Returned   : 5
        Fields Returned : 5
        System time     : 10000

0>

Ironically I originally developed the precursor to SQL Relay on an SCO OpenServer system to run against Oracle 7. These days I don't have a copy of Oracle 7 and even if I did, I long removed support for it. OpenServer has been relegated to client-only status.

Oh well, times change.

Quirks

Aside from the quirks I mentioned above, I ran into a slew of other oddities while fiddling with OSR505. Some can be attributed to its age, others to SCO's commitment to back-compatibility. Others, I'm just not sure about.

  • At boot there are options for entering single-user mode and setting the date/time. There are timeouts for both prompts. However, hitting enter at the initial boot prompt disables the timeouts and makes it sit on the prompt to enter single-user mode forever.
  • On the command line, hit delete instead of ctrl-C.
  • Home directories are created under /usr.
  • Root's home directory is /.
  • There is no "which" command.
  • PATH is set in /etc/default/login for console logins but ssh appears to hardcode its own PATH before running .profile.
  • /usr/bin/X11 isn't in the PATH by default.
  • ./ is in the PATH.
  • The shell doesn't know about ~.
  • The package manager automatically selects the first package. So, if you want to uninstall something, you have to make sure to unselect the first package or it will get uninstalled too.

And, the quirk that confounds automated remote scripting over ssh:

The .profile runs a tset command that guesses your terminal type and then prompts you for whether it was correct or not. This makes ssh'ing remote commands a pain because you have to hit return manually to accept the terminal type. Without this command, the TERM type appears to generally get set correctly. Just comment it out in the .profile:

#eval `tset -m scoansi:${TERM:-scoansi} -m :\?${TERM:-scoansi} -r -s -Q`

TODO

I had a lot of fun installing OSR505 and it was a nice walk down memory lane, but I haven't yet gotten to do everything I wanted to.

It would be cool to:

Get the webserver working and serving CGI's.

Find Java and get my java code working with it.

Get xauth working, maybe by installing X11R6.

Get postgresql working, maybe by building from source.

Get my software to compile with the native toolchain and optimizing compiler.

SCO supported IPX/SPX and NetBEUI, had an Advanced File and Print Server that predated SAMBA and had a Volution Messaging server that was compatible with older versions of Exchange Server. I think all of that is on the install CD. It'd be neat to get all of that working.

Earlier versions of OSR5 came with Wabi and Merge. Wabi means Windows ABI and was an environment similar to Wine that allowed you to run Windows 3.1 apps on SCO. It even came with a graphical desktop similar to 3.1. It was dog slow in the 90's but might run OK now if I can find it. Merge was the predecessor to Win4Lin. Basically Win4Lin was a port of Merge to Linux. The Merge that came with OSR only supported Windows 3.1 though, I think. It'd be cool to locate that software and play with it.

My Dad has floppies for Microsoft Basic for Xenix, Microsoft Word for Xenix, Foxplus and maybe even Foxpro for Unix. It'd be fun to intall those and play around with them. We wrote so much code in Basic and Fox, you can't begin to imagine.

Get Oracle 7 working again. We once had the installation CD's for 7.4.3 and 7.4.4. I might be able to dig them up.

Ahhh, some day... Some day.

Saturday, October 19, 2013

NetBSD - 6.1.2 x86

NetBSD 6.1.2 apparently came out sometime recently when I wasn't looking. I have probably a half dozen NetBSD installations running in various emulators, but my primary NetBSD development environment is x86. I'll get around to upgrading the others in due time, but the x86 VM can't wait. It can't!

Installation

As with most OS'es these days, you can either download a DVD image with everything on it and install from that, or you can do a netinstall over FTP or HTTP or something. I usually go with the netinstall unless I'm installing some really old version that's hard to find, and I went with the netinstall in this case too.

I downloaded the boot iso from: ftp://ftp.netbsd.org/pub/NetBSD/NetBSD-6.1.2/i386/installation/cdrom/boot.iso, aimed VMware at it and began the installation.

VMware always wants to know what kind of OS you're using but never gives you a NetBSD option. Other -> FreeBSD has always seemed close enough and I went with it again this time. I wonder exactly what the difference between that and Other -> Other would be though. I know you get IDE disks with FreeBSD and it defaults to 20g rather than 8g but there's probably something else too. Maybe I'll look into that some day.

Other settings... 8G disk, bridged Network Adapter, 800 x 600 display, 256M of RAM. I also removed the Floppy, USB and Sound Card.

NetBSD runs in a lot of emulators so I've probably done more NetBSD installations than anything else. The installation process always seems pretty straightforward to me. Just follow the prompts.

I selected Full Installation, Use Entire Disk, Use Existing Partition Sizes and installed from FTP. I also declined IPv6 autoconfiguration.

Pretty soon, I was in business.

I've always liked how the installer shows you the full ftp session output.

NetBSD 6.1.2 i386 - 1 install

The downloads are getting quicker every year. I'm always surprised how quickly an entire distro comes down.

As of 6.1, I think, but maybe 6.0, after the sets are installed there's a menu that lets you configure the network, timezone, root password, etc. You can bypass all of it if you like but I usually go down the list, configuring each thing.

It's important to "Enable installation of binary packages" and "Enable sshd" but I chose not to enable ntpd, ntbdate or mdnsd.

I also got a little concerned when pkgsrc stalled out at the end but it eventually finished so I guess everything is OK there.

When the installation is over the installer drops you back at the main menu.

Reboot!

Success!

NetBSD 6.1.2 i386 - 2 first login

Post-Install Tweaks

I don't usually like poking around as root, so the first thing I do with a new system, unless I was able to do it during the installation, is create a user for myself.

NetBSD has the standard useradd/userdel commands.

useradd -m -G wheel dmuse passwd dmuse

The -m creates a home directory and the -G wheel adds the user to the wheel group, making it possible to su. On linux and some other platforms those options aren't necessary but it I believe it is on all of the BSD's. useradd doesn't prompt for a password so that's important to run afterward.

The next thing I usually do is make it possible to sudo without a password. Unfortunately sudo isn't installed by default but fortunately, NetBSD supports pkgin, and by virtue of selecting the "Enable installation of binary packages" option during the installation, I can install sudo easily.

pkgin install sudo

pkgin is great. It's similar to apt-get and yum. You can list available packages, search for packages, install them over the internet (with dependency resolution) etc.

It even has a feature that I'm not sure how to do (or if you can) with apt-get and yum. If you manually install a package and it drags in dependent packages, but then you uninstall the main package, the dependent packages are orphaned. It would be great to uninstall them as well but who keeps track of all the dependent packages that got installed along with the one you meant to install? Pkgin does. Those packages are marked auto-removable, as nothing else depends on them. You can run "pkgin autoremove" and it will remove all auto-removable (orphaned) packages. Awesome.

There is a significant quirk though. It appears that if you install a meta-package (ie. a package that doesn't install anything, only has dependencies that cause other packages to be installed) then the dependencies themselves get marked as having been installed directly and can't be removed automatically. This is particularly frustrating when you install something large like the Gnome desktop and then attempting to remove it, expecting autoremove to do most of the work for you.

But I digress.

I was in the middle of configuring sudo...

NetBSD puts its packages in /usr/pkg so the sudoers file is in /usr/pkg/etc. I appended to it:

dmuse ALL=(ALL) NOPASSWD: ALL

All right, no more logging in as root.

I enabled sshd during installation. xauth was installed as well. X11 Forwarding wasn't enabled by default though, so I enabled it by editing /etc/ssh/sshd_config and setting:

X11Forwarding yes

then restarting ssh

/etc/rc.d/ssh restart

After that I copied my entire .ssh directory from another VM and was able to ssh into the NetBSD VM without a password.

All right, no more logging in on the console.

ssh, scp, sftp and ftp all appeared to be present. tar, gzip, bzip2 and unzip appeared to be present as well. zip was conspicuously absent but quickly installed:

sudo pkgin install zip

Web

On the client side, I like to have firefox, lynx and wget available and apache on the server side. None were installed but all were available. "pkgin search firefox" and "pkgin search apache" revealed several options for each but it looked like "firefox" and "apache" would install the latest version.

sudo pkgin install firefox lynx wget apache

The apache config file appeared to be /usr/pkg/etc/httpd/httpd.conf with DocumentRoot /usr/pkg/share/httpd/htdocs.

I enabled cgi's.

LoadModule cgid_module lib/httpd/mod_cgid.so
...
AddHandler cgi-script .cgi
...
Options Indexes FollowSymLinks ExecCGI
...
DirectoryIndex index.html index.cgi

Apache for NetBSD comes with an example init script but it's not installed by default. I installed it...

sudo cp /usr/pkg/share/examples/rc.d/apache /etc/rc.d

...and enabled it by adding the appropriate line to /etc/rc.conf

apache=YES

Then started apache. Would my test program work?

#!/bin/sh

echo "Content-type: text/plain"
echo
echo
echo
/usr/bin/env

Yes!

Excellent. Moving on.

Graphical Desktop

What kind of graphical desktop could I get working? A few pkgin searches revealed Gnome 2 and 3, KDE 3 and 4 and XFCE 4 but no obvious metapackage stood out for any of them.

After a little digging on the web I found the pkgsrc meta-packages list for 6.1.2 at ftp://ftp.netbsd.org/pub/pkgsrc/packages/NetBSD/i386/6.1.2/meta-pkgs/. It looks like "gnome-platform" will get me Gnome 2, "kde" will get me KDE 3 and "xfce4" will get me XFCE 4.

Well, as it turns out, gnome-platform doesn't get you all of Gnome 2. To get it, you have to manually install tons of individual packages and it's difficult to figure out which. Worse, if you get started and want to bail, pkgin autoremove doesn't work help because gnome-platform is a meta-package.

XFCE 4 looked like a better choice...

sudo pkgin install xfce4

The list of dependencies looked more realistic.

I created my .xinitrc...

/usr/pkg/bin/xfce4-session

... switched back to the console and ran ...

startx

Voila!

NetBSD 6.1.2 i386 - 3 xfce

I love their little mouse logo.

All right, what about a graphical login? XFCE doesn't have its own and they recommend using gdm, lightdm, slim or lxdm. Of that list, pkgin only knows aboug gdm. Maybe plain old xdm would work. It was already installed.

I created an .xsession file with:

/usr/pkg/bin/xfce4-session

appended...

xdm=YES

to /etc/rc.conf and rebooted.

Well, it wasn't pretty, but it worked:

NetBSD 6.1.2 i386 - 4 xdm

And logging in got me an XFCE session too.

What about the web browser...

I clicked on "Web Browser" and it ran "Nightly" but "Nightly" looked a lot like Firefox. I checked the Preferred Applications settings in XFCE and they were set to use Firefox as the web browser. Indeed, running firefox from the command line in a terminal ran "Nightly" as well. Does "Nightly" mean "nightly build of Firefox"?

At any rate, I aimed it at my trails site and it worked as expected. The fonts were a little big, but zooming out by 1 took care of that.

NetBSD 6.1.2 i386 - 5 browser

Productivity

Were there any productivity apps available? It appeared so. pkgin could see LibreOffice 3 and 4, OpenOffice 3.1, KOffice, fengoffice and various other packages.

sudo pkgin install libreoffice4-bin

LibreOffice had some interesting dependencies like suse_base, suse_x11, suse_libtiff, etc. NetBSD supports binary emulation. Maybe LibreOffice was just a linux app with the necessary support packages.

pkg_info -L suse_base sure made it look like it was. Everything was stored under /usr/pkg/emul/linux. Interesting.

I had to run it from the command line using "soffice" and it complained about a non-existent java vm and threw a bunch of dbus/gconf errros but in the end, it worked:

NetBSD 6.1.2 i386 - 6 libreoffice

Impressive sir!

AbiWord and GNUmeric were also available and appeared to be native NetBSD apps.

sudo pkgin install abiword abiword-plugins gnumeric

They integrated better too, showing up in the XFCE menu after installation and appearing as the default .doc handler for Firefox (or Nightly).

NetBSD 6.1.2 i386 - 7 abiword

Development

All right, enough of that. I'm ulimately setting up this VM to test my software on.

Some packages that I needed appeared to already be installed: gcc/g++, pcre, openssl, apr, perl, sqlite, cvs

But even more needed to be:

sudo pkgin install readline php ruby tcl erlang openjdk7 mysql-client postgresql92-client unixodbc freetds gmake vim-gtk2

I copied my .cvsrc and .vimrc from another VM and some build scripts too, checked out my source code and ran the main build script.

Everything built.

To test it I had to add /usr/local/firstworks/bin to my PATH and /usr/local/firstworks/lib to my LD_LIBRARY_PATH. The BSD's in general are difficult to set system-wide paths on because the .profile scripts override anything you set in /etc/profile so I just added them to my .profile instead of setting them system-wide.

After that, I could run the sqlrelay server against the different databases that I was able to build support for. sqlrsh could connect just fine to the instance on my linux host connected to oracle.

NetBSD 6.1.2 i386 - 8 sqlrsh

Everything appeared to work as expected.

Clean Up

I don't need X Windows for most of what I do so I disabled xdm in /etc/rc.conf

xdm=NO

and rebooted. During the reboot I reduced the VM's memory configuration to 128M. That's always been plenty in the past.

Quirks

I did run into some interesting quirks.

Shell aliases need to go in a particular location in ~/.shrc rather than in ~/.profile directly or it causes all kinds of problems. I don't remember that from 6.1.1 but maybe it was an issue in that release too.

XFCE itself doesn't appear to read ~/.profile and its terminals don't either. On top of that, the shell doesn't understand ". .profile" or "source .profile". To get my PATH settings, I had to run a terminal, then run bash and manually source my .profile. I'm sure there's some way to fix that but it was very confusing.

There's also a swap partition issue. No swap partition was created by the default installation options but the system was configured to save core (in case of a kernel panic) to the nonexistent swap partition. /etc/rc.d/swap2 complains that there isn't one too. It's possible to add a swap file by running:

dd if=/dev/zero of=/swap bs=1m count=256
chmod 600 /swap
swapctl -a -p 1 /swap

and adding to /etc/fstab:

/swap none swap sw,priority=1 0 0

but the kernel can't dump to that so it's only a half fix. Very strange. I'll have to keep that in mind for next time.

Sunday, October 6, 2013

FreeBSD - 9.2 x86

Upgrade time!

FreeBSD 9.2 just came out and last night I felt compelled to upgrade.  Compelled!

Would my software still compile and run?  Did they fix the issue I had in 9.1 where pkg_add -r didn't work for large enough files.  Who knows!?  I would find out.

The netinstall image was available, as they usually are, from ftp://ftp.freebsd.org/pub/FreeBSD/releases/ISO-IMAGES/9.2/FreeBSD-9.2-RELEASE-i386-bootonly.iso. I downloaded it forthwith, aimed my VMware Workstation at it and let the adventure begin.

"Select a Guest Operating System" it said. "Other -> FreeBSD"  seemed like a logical choice.  I also changed the 20g hard drive image to 8g (which was enough with 9.1) but accepted the default 256M of memory.  Later, the disk turned out to be IDE.  I wonder if I'd get better performance out of SCSI.  Some day I'll test that, but not today.  I didn't need a Floppy, USB or Sound Card so I removed the emulated versions of those, switched my Network Adapter to Bridged (and to replicate physical network connection state) and set the Maximum resolution of any one monitor  to 800 x 600.

Installation

Boot!

FreeBSD-9.2 - 1. boot screen
Interesting. I don't remember a multi-color bootloader in 9.1. Maybe there was one though and I just don't remember it. I like it.

On the "Distribution Select" screen, games was already checked but I checked doc, ports and src too to get a more complete installation.

I'm using static IP's on my network so I opted out of DHCP autoconfiguration but noticed something quirky when attempting to enter my IP, netmask and gateway.  Hitting return after entering a value in a field takes you to the next screen rather than the next field and hitting tab takes you down to the OK/Cancel buttons rather than the next field too.  I had to use arrows to navigate between the fields.  Unusual.

Ok.  Static IP, no IPV6, let's go.

I selected Guided partitioning and used the Entire Disk.  The default partitioning looked good - a small boot partition and the rest was swap and root.

Pretty soon the installer was downloading sets.  The download was surprisingly fast.  I went to get a glass of soda and the Overall Progress was already at 15% when I came back.

FreeBSD-9.2 - 2. downloading
That said, for whatever reason, set extraction seemed to take a while.  Another reason to test that emulated SCSI drive some time, I guess.

Eventually everything was installed.  On the System Configuration screen, sshd was already checked and I didn't enable moused (mouse on console), ntpd or powerd.

I did create a user and was surprised at how many options there were.  Most OS'es prompt for the login name, full name and password, maybe additional groups.  FreeBSD asks a whole page of questions, all relevant questions, but man... a lot of questions.

A minute or two later I rebooted and got my first login prompt.

FreeBSD-9.2 - 3. first login
Post-Install Tweaks

I logged in and checked to see what was running.  Not much, actually, which was nice.  I usually have to stop a ton of unused processes, but not this time.  Sendmail was running, but after poking around a bit I learned that it was configured for local delivery only.

There was an odd adjkerntz process running but after looking at the man page it seemed wise to leave it running.

I'd created a user for myself but quickly realized that I'd forgotten to add myself to the wheel group.  Oops.  Maybe I should have paid more attention on that long page of options when I created the user to begin with.

I usually install sudo almost immediately after installation.  FreeBSD still doesn't appear to have an equivalent to yum search or apt-cache search but I figured I could probably guess the package name.

pkg_add -r sudo

Yep, not too hard.  The sudoers file was in /usr/local/etc though, not /etc.  I guess this makes sense as the rest of sudo was installed under /usr/local but it took me a minute to find it.  sudoers is in a different place, I never remember that about FreeBSD.

sshd was running already but I installed xauth so X-forwarding would work.

pkg_add -r xauth

I copied my .ssh directory from another machine and was instantly able to ssh into the VM from elsewhere.  No more working on the console.

Web

What kind of web software do we have.  Nothing came in the base install, it seemed, so I installed firefox, lynx and wget.

sudo pkg_add -r firefox lynx wget

firefox pulled in a lot of x-windows stuff (which I expected) but unexpectedly pulled in perl and python too.

On the server side, I installed apache.  Or at least I tried to.  pkg_add of apache, apache2 and httpd all failed.  What's it called again on FreeBSD?  No good way to find out (that I know of) other than ftp'ing in and looking around.

ftp ftp.freebsd.org
cd cd pub/ports/i386/packages-9.2-release/Latest
dir *apache*

There appeared to be apache22 and apache24 options.

sudo pkg_add -r apache24

The install script gave me this helpful message too:

To run apache www server from startup, add apache24_enable="yes"
in your /etc/rc.conf. Extra options can be found in startup script.

Thanks for that.  I added the enable line, but how do you actually start apache again?  There was no /etc/rc.d/apache*.  "grep -r apache /etc" was unrevealing

Finallly, "pkg_info -L apache24-2.4.6" revealed an init script in /usr/local/etc/rc.d/apache24.  Got it.  Should have remembered that.

The config file was in /usr/local/etc/apache24/conf/httpd.conf.  The DocumentRoot was set to /usr/local/www/apache24/data.

I enable cgi's...

LoadModule cgi_module libexec/apache24/mod_cgi.so
...
AddHandler cgi-script .cgi
...
Options Indexes FollowSymLinks ExecCGI
...
DirectoryIndex index.html index.cgi

...and started the server

/usr/local/etc/rc.d/apache24 start

I wondered if that would get started at boot time or not.  Does the init process look in /usr/local/etc/rc.d?  I'd find out later.

Do cgi's work?  Sometimes they don't but this time they did.  My little test program worked fine with lynx:

#!/bin/sh
echo "Content-type: text/plain"
echo
echo
echo
/usr/bin/env

Productivity

What kind of productivity tools were available?  I'd have to ftp in again to find out.  Looks like LibreOffice is available.  Excellent.

sudo pkg_add -r libreoffice

In 9.1, downloading a large package would sometimes cause pkg_add to stall out.  Not this time though.  It took a while but everything was successfully downloaded and installed.

I guess I jumped the gun a bit with that LibreOffice install though.  To actually run LibreOffice, it's generally helpful to have X running first.

Graphical Desktop

What desktops are available?  I had to ftp in again to find out but I was pleasantly surprised.  Gnome 2, KDE, XFCE 4, LXDE and E17 all appeared to be available.  Gnome 3 was missing but it requires hardware acceleration and I'd have installed Mate instead anyway.

Let's try Gnome 2.

sudo pkg_add -r xorg gnome2

This took forever.  I was reading a book while waiting and after several chapters, I just gave up and let it run all night.  The next morning it was installed though and I tried it out.

There were a few things that I didn't remember from my last FreeBSD install but I did remember that X on FreeBSD requires hald and dbus.  They were installed with xorg but not enabled so I added lines to /etc/rc.conf to enable them:

hald_enable="YES"
dbus_enable="YES"

X also requires /proc so I added a line for it to /etc/fstab...

proc /proc procfs rw 0 0

... and then I started everything up.

sudo mount /proc
sudo /usr/local/etc/rc.d/hald start
sudo /usr/local/etc/rc.d/dbus start

To just run gnome from the command line you have to make sure there are no .startxrc or .xsession files in your home directory, create an .xinitrc with:

/usr/local/bin/gnome-session

and run:

startx

I switched back to the console and tried it.  It almost worked.  I got a beautiful desktop but the mouse didn't work.  After some poking around it appeared that hald wasn't running.  Ah, who knows, just reboot.

Upon reboot, hald, dbus and apache all 3 came up.  I guess the init process does look in /usr/local/etc/rc.d.

I tried startx again and the mouse worked fine.  The first terminal I opened died immediately but the next one opened fine.  I've never been able to reproduce that and had no other problems at all.  I have no idea what caused it.

I fired up Firefox and pointed it at my trails site.

FreeBSD-9.2 - 4. firefox
It seemed slow to start but ran well once loaded.

LibreOffice writer seem slow to start as well.

FreeBSD-9.2 - 5. libreoffice

Neither guest nor host were paging.  I thought fs caching might improve things and Firefox did seem to start more quickly the next time but LibreOffice still didn't.  The System Monitor said I was only using about 36m of ram (out of 256) but now using 131m of swap.  Hmm.  Something's going on.  No time to fiddle with that though.

VMware tools.  Could I get them working?

I clicked "Install VMware Tools" in VMware and (as expected) nothing happened.  I had to manually mount cd  but that took a little digging to figure out.  I'm sort-of used to mount attempting to detect the filesystem type and also sort-of-used to the filesystem type being iso9660, but it doesn't and it wasn't.  No problem though, I figured it out:

sudo mount -t cd9660 /dev/cd0 /mnt

Installation was a little tricky though.  It started off easy.

tar xfz /mnt/vmware-freebsd-tools.tar.gz
sudo vmware-tools-distrib/vmware-install.pl

I accepted the defaults.  At the very end it errored out.  Apparently I needed to install compat6x-i386.  No problem.

sudo pkg_add -r compat6x-i386

I re-ran installer and re-accepted defaults.  This time it got further but I got some semi-confusing messages at the end: "No X install found" "Unable to start services for VMware Tools"

Maybe a reboot would help.

Kind-of.  The messages said to run /usr/local/bin/vmware-config-tools.pl

I did and it still gave errors regarding memory manager and blocking file system but it appeared to recognize X.  I ran startx and, hey! the cursor automatically moved in and out and I could resize the screen.  Woohoo!  I'll call that success for now

To get a graphical login I append some lines to /etc/rc.conf:

gdm_enable="YES"
gnome_enable="YES"

And I'm sure there's some way to start GDM from the console but I just rebooted again.  Upon reboot I got the expected graphical login manager.

FreeBSD-9.2 - 6. gdm

Logging in took a while.  Everything seemed generally sluggish but once it was loaded it was very usable.

It's fun to get the graphical desktop working but in truth, I prefer to run my VM's in text mode.  I usually just ssh into them to test software and there's no need to consume the extra memory.  So I disabled the graphical login...

gdm_enable="YES"
gnome_enable="YES"

...and booted back into text mode.

Development

Development is what I'm really up to with these VM's.  I make sure my software compiles and runs on them.  The more platforms and compilers you expose your code to, the more likely it is to compile and run on platforms you don't have access to.  Or something like that.

g++, perl, python and ruby appeared to have been installed already, as were pcre, openssl, apr, curl, libexif, and librsvg2.  For some reason, proj was even installed.  I didn't realize anyone but me ever used it but apparently so.

I did need to install a few languages, database API's and tools so I ftp'ed in to the ftp site again and discovered the names of the packages I needed to install.

sudo pkg_add -r gmake vim php55 tcl86 erlang openjdk7 readline unixODBC mysql56-client postgresql92-client freetds freetds-devel sqlite3 mdbtools p5-Image-ExifTool gdal

freetds-devel is the oddball.  Why a separate devel package?  That's standard on Linux for sure, but not on any of the BSD's.  Odd.

In 9.1 pkg_add had stalled out on erlang and openjdk7 and I had to manually download and install them, but it worked this time.  Woohoo!

I copied over my .cvsrc, and .vimrc files from another VM, tweaked my .profile a little and...  ahh, come on:

E25: GUI cannot be used: Not enabled at compile time

Really?  gvim was compiled without support for the GUI?  I guess so.

I checked out and built all of my code.  No surprises, everything compiled and installed just fine.

Updating the system-wide PATH is always difficult on FreeBSD because the user-specific .profile overrides it entirely so rather than updating /etc/profile, I added /usr/local/firstworks/bin to the PATH and /usr/local/firstworks/lib to the LD_LIBRARY_PATH in my .profile.

sqlrsh worked as expected.

FreeBSD-9.2 - 7. sqlrelay

(I fired up the GUI one last time to get that screen shot)

Running sqlrelay against mysql, postgresql, sqlite, etc. all worked as expected and my test programs worked against it.  All right.  I'll, of course, do more testing later but for now it looks like FreeBSD 9.2 is supported.

Clean Up

Since I'm not running a graphical environment, I disabled hald and dbus in /etc/rc.conf...

hald_enable="NO"
dbus_enable="NO"

...and rebooted.  During the reboot I tuned VMware down to 128M of RAM too.

Conclusions

None!

Or at least almost none.  There were a few quirks but I have yet to install an OS that didn't have any.  Besides, I'm not here to critique the OS, just to explore it and support it if I can.