Category: OpenBSD

UNIX and OpenVMS Online Resources

It is possible to get free online access to UNIX or to OpenVMS; these can be useful in building up your experience on a platform when starting from scratch – or when a review is required.

One of the oldest public access systems in the country is the Super Dimension Fortress (or SDF as it is usually called). SDF offers free accounts, but does ask for US$1 to gain standard access. This isn’t because access is expensive, but because too many people have used the facilities for nefarious purposes (the process suggests that the new user is not a person who will strike and leave).

SDF runs NetBSD on DEC Alphas; this was driven mainly by security and stability. Previously, Stephen Jones, the proprietor, ran SDF using Linux on Intel for several years (which he describes as “the dark years”). BSDTalk had an interview with him back in 2006.

You could also try PolarHome – this shell provider provides access to hosts running Linux (Red Hat, Debian, SUSE, Ubuntu, or Mandriva), OpenVMS (Alpha or VAX), OpenBSD, FreeBSD, NetBSD, HPUX, IRIX, QNX, Solaris, Ultrix, AIX, Tru64, and OpenStep. Unfortunately it requires payment for shell accounts – again because of abuse. The payment is 10 units of your local currency or US$2, whichever is more – and this is per host as well. No other site provides this diverse of a selection.

For truly free UNIX shell accounts, one can try Grex, which is a more professionally-run system (Polarhome and SDF are sole proprietorships). Grex offers totally free shell accounts, but also has memberships (for people to help support the site). It is possible that Grex has the most users as well. Like the others, paid membership does have its privileges – but unlike the others, membership is mainly to provide support for Grex, rather as a security feature.

For OpenVMS, there is a very unique online shell provider: Deathrow Cluster. This is a cluster of three machines running OpenVMS 7.3 – one VAX, one Alpha, and one emulated VAX (SIMH) on a dual Xeon machine. This last is a perfect example of what can be done with an emulator, especially with SIMH which can emulate all manner of old Digital and IBM hardware. However, SIMH does not emulate the Digital Alpha, unfortunately. Like Grex, Deathrow provides completely free shell accounts; like SDF and Polarhome, it is (or appears to be) mainly one person’s purpose to keep it running with a lot of volunteer help.

Any of these will be good sources to keep your shell skills sharp – and in some cases, programming as well. They’re also good people to support; why not offer them some donations if you can?

Converting OpenBSD 4.1 guest from VMware to VirtualBox

This turned out to be easier than it would appear, although the vmware-tools needs to be extracted from the system.

The first thing that I did was to add the virtual hard drive created by VMware to the list of hard drives that VirtualBox makes available. This is in the Virtual Disk Manager from the main menu (Ctrl-D).

VirtualBox has native support for VMDK disks, the format that VMware uses. However, the documentation suggests there are restrictions, although the documentation may be obsolete: for one, it appears that snapshots are now possible, although the documentation suggests otherwise.

Having added the disk using the Virtual Disk Manager, I then created a new virtual environment and used the disk instead of creating a new disk from scratch. The disk was picked up and used seamlessly.

However, booting the environment (predictably) had problems: the VMware root disk was /dev/sd0a, but the VirtualBox root disk was /dev/wd0a. Thus, everything was fine until /etc/fstab was read, then OpenBSD presented the option to utilize a shell to fix the problem.

At the shell, it was necessary to mount the root filesystem read-write:

# mount -o rw /dev/wd0a /

Then editing /etc/fstab to use the correct disk was all it took.

However, VMware does not use an OpenBSD package to install the software, and apparently just drops it into the environment – and not in /usr/local either. All of the BSDs fiercely recommend placing every addition to the system in /usr/local – every add-on package does, from BIND to PHP to Apache to KDE to OpenOffice – everything. So for VMware to litter across the filesystem in this manner is very bad taste – and even without a package to extract it from the filesystem properly.

However, using locate, we can find the vmware-tools (or what looks like all of them):

# locate vmw
/emul/freebsd/sbin/vmware-guestd
/etc/vmware-tools
/etc/vmware-tools/installer.sh
/etc/vmware-tools/not_configured
/etc/vmware-tools/poweroff-vm-default
/etc/vmware-tools/poweron-vm-default
/etc/vmware-tools/resume-vm-default
/etc/vmware-tools/suspend-vm-default
/var/log/vmware-tools-guestd
/var/run/vmware-guestd.pid
#

These files and directories can then be removed, although if the disk is to be used by VMware again you may not want to. However, using a virtual environment in two different products on a regular basis sounds like a recipe for disaster.

Is FreeBSD a better choice for the desktop? (or dispelling myths)

It’s strange I should come across this article in one of my favorite blogs just after I switched from my FreeBSD desktop to Kubuntu. I’m also surprised at the lack of knowledge and the propagation of some long-standing myths about Linux and FreeBSD for that matter.

There are some ways that FreeBSD (or better put, BSD) is better than Linux – but the comparisons must be valid and appropriate without myths and falsehoods.

Perhaps the primary myth is that FreeBSD is a complete operating system and Linux is a boat-load of different distributions in all different flavors with different setups and so on. However, FreeBSD also has a large number of alternatives, including OpenBSD, NetBSD, PCBSD, DesktopBSD, PicoBSD, and Dragonfly BSD to name just a few.

Another comparison is that FreeBSD is put together by the FreeBSD Core team and that this is better than Linux (which has a “benevolent dictator” model). There’s no discussion of OpenBSD, for instance, which also follows this “benevolent dictator” model. There’s also no comparison to Red Hat Enterprise Linux, for example, which has a large number of people working towards putting together a complete distribution, not just the kernel.

The documentation is definitely an argument in favor of BSD – virtually everything that is in the system anywhere is documented in the online documentation, and the FreeBSD Handbook is without equal. It can be proven programmatically that there are commands in Red Hat (or other distributions) that are not documented. I daresay that the FreeBSD documentation beats other BSD variants as well.

Another benefit of FreeBSD specifically is the vast number of ports available. There are more ports for FreeBSD than any other system but Debian GNU/Linux. The sheer amount of packages available in both environments has made them appealing to me – and perhaps to others. Where else are you going to get Steel Bank Common Lisp for example? Both Debian and FreeBSD have it.

The article specifically asked about FreeBSD for the desktop: FreeBSD is definitely not ready for the desktop at all. When I installed it for my desktop (twice now), the basics are there certainly – but there were numerous problems that I had to overcome. Among them, I had to set up my own system bootsplash, and had to configure and set up my own login screen (kdm). USB devices plugged in weren’t properly recognized. Hibernation and sleep didn’t work. Flash doesn’t work. Unlike what has been said before, the drivers are much less available than they are for Linux: hardware manufacturers don’t see a need to support BSD, and many new UNIX users (and developers) don’t see a need to use anything but Linux. Wireless support is perhaps an exception, but that development is centered in OpenBSD, not FreeBSD.

There is also, in my mind, a benefit to BSD that goes often unmentioned: it has the smallest kernel of the open source UNIX and Linux kernels out there today. FreeBSD and OpenBSD will run in smaller environments that Linux won’t: on my 512M laptop, a Compaq Armada E500, Fedora 5 would crash during the install (not enough memory) – whereas the much more current FreeBSD 6.2 installed just fine.

Now, when I installed Kubuntu onto a Compaq nc4010 with 1G of memory, it went will – and it recognized everything – wireless, hibernate, bluetooth, USB devices, PCMCIA, video display, power capabilities, etc. – all without special configuration. (I might note that, here too, on this machine Fedora crashed – this time the Live USB Fedora 9 crashed during exit – sigh…) Preconfigured and tested support for Flash, Java, and MP3s was a click away.

When it comes to the desktop, FreeBSD has a long way to go (perhaps PCBSD is a lot better?). However, on the server end, I would propose that FreeBSD is a better way to go than Linux in many cases (except for OpenBSD might, in my opinion, be even better). It is unfortunate that none of the BSD variants are often considered for enterprise server use – especially considering FreeBSD is commonly found in NetCraft‘s list of top uptime.

Finding devices for your open source operating system

In a Windows environment, people have gotten used to just picking up any device (whether it is a CDROM, PCMCIA card, printer, or modem) and expecting it to work. While the concept of “plug and play” is not yet here, the fact is that when installed everything should work with Windows.

And it isn’t just Windows – other large commercial vendors have access that you and I do not. Apple comes to mind – MacOS X has much better support than Linux or FreeBSD, for example.

Open source operating systems rely on hardware manufacturers to make the details of their hardware available for free or low cost – and then for someone to come and craft the software drivers needed. Usually, the latter is not a big problem; the former is.

The problem can be deeper than that as well, since the label on the product is not the same as the label on the internal devices: so it is not possible to simply look for a brand and use it. Worse, manufacturers can change hardware vendors on the same model, so that discerning which model is which can occasionally be difficult – the revision becomes the determining factor as to which hardware was used.

First thing is to determine which devices are supported. Start with the release documents for the operating system and look for supported hardware. Another place to look is the man pages (or other documentation) for the drivers. Keep the list of specific hardware handy, on another screen or printed out.

Then, look for the device (or devices) at your chosen store. Write down what you find, even if it isn’t listed (and even if it is). Then look up the device on the Internet using your desired search engine. Pay attention to mailing list threads and watch what sort of trouble people had (or didn’t have). The mailing list threads should also help you identify the hardware sources used in otherwise unidentified products, and also will keep you up to date on people’s experiences.

Once you have a product chosen, given few problems on mailing lists and a well-supported and identified hardware chip set, then buy it. However, for best results, make sure there is a good return policy in case it doesn’t work – otherwise, you are taking a chance (albeit a very small one if you’ve done your homework).

I’ve gone through this with several wireless cards under FreeBSD. The first was the Netgear MA401 (researched as given here) – worked flawlessly until it was smushed. The second I received as a bonus with my laptop purchase was a Zonet 1502 (definitely a mistake, but it came with the laptop). I’m sure the Zonet works fine under Windows (and probably OpenBSD: they reverse engineered the driver). Currently, I’ve added a TP-Link TL-WN610G (again researched as described here) – also working flawlessly.

This isn’t just good practice for wireless cards, though – networking cards, mice, video – all benefit from this research. Even laptops: when I bought my laptop, I researched the two brands that were available (for sale used at my favorite local used computer store) and found that one had lots of difficulties and the other did not. Guess which one I bought?

FreeBSD on the fitPC and on the EeePC

FreeBSD is a nice environment, and I tend to gravitate to it (though I love Linux and Solaris as well). It does tend to work better in smaller environments than either Linux or Solaris.

There was recently a discussion of FreeBSD on the EeePC; it appears that while some items do not work (to be expected) it runs nicely and works nicely (including wireless). There was recently posted a simple introductory article which also refers to a comprehensive article on FreeBSD on the EeePC.

There was also an article (with followup) about running FreeBSD on the fitPC; in contrast to the EeePC, this sounds like it is not as good. However, the fitPC has less memory and a slower processor; it is unclear as to whether the processor is “fast enough” (I still use Pentium IIIs for my use!) or if it really is slow. It is, however, very surprising that the default Ubuntu install would be a graphical installation that swaps badly and comes without SSH.

The fitPC forums have a nice Linux on fitPC section, which also includes the BSDs as well. The biggest problem with FreeBSD seems to be its lack of a USB CDROM driver in the base kernel; however, apparently OpenBSD loads fine. Since the system has only 256M of memory, it perhaps should not be swamped with heavy desktop applications.

Using OPIE

Setting up OPIE (One-time Passwords In Everything) in OpenSUSE was easy: there is a opie RPM in the standard repository, and it installs cleanly and easily.  Then it is just a matter of initializing the database and modifying the PAM configuration to match.  Then each user is added to the database (/etc/opiekeys) one at a time.  I’ll describe the exact process on OpenSUSE at a later time.

Insufferingly, it appears that Fedora (and Red Hat) do not offer any form of one-time passwords anywhere – and certainly not OPIE.  RPMs for opie are exclusively for OpenSUSE and for the Polish PLD distribution (both of which seem to have everything).  How extremely frustrating!  This sounds like a good time to switch my home system from Fedora 5 to OpenSUSE 10.3.

OpenSUSE has supported LVM, XFS, KDE, and many other technologies when Red Hat staunchly refused to.  Even now, OpenSUSE support for all of these is much more integrated and time-tested than Red Hat’s.

Lest I sound like I hate Red Hat – I don’t – and that’s what makes it so frustrating.  Grrr….

The search for one-time passwords for HP-UX and for OpenVMS was even more fruitless.  HP-UX apparently has a third party skey package available; OpenVMS has nothing – though it could be added through programming the ACME interface (which provides similar capabilities to PAM – though perhaps not as flexible).

It looks like the BSDs aren’t a lot better: FreeBSD has OPIE built into the core (with a full section on OPIE in the FreeBSD Handbook on it); NetBSD and OpenBSD do not appear to have it (!).

Looks like my settling in to FreeBSD and OpenSUSE has paid off.  I don’t even need to suggest Debian – Debian has everything – and OPIE is no exception.  And of course, Ubuntu follows suit as well.

Running Linux/UNIX under VMware Server 1.0

I have the distinct pleasure of having tried a number of systems under VMware Server, including OpenSUSE 10.3, Kubuntu 7.10, OpenBSD, and Solaris Express Developer Edition.  All work quite nicely.

There is one caveat – this environment uses a dual-monitor setup for Windows, and if the emulator autodetects the desktop size it expands to something approximating the two monitors put together.  The emulated environment works just fine (usually) with this screen, but it can’t be used in full-screen mode (since that goes to one screen only).

In that line of video mishaps, Solaris detected the video but only wants to allow 1024×768 (I’ve 1280×1024 here).  Whatever.

I also did not try OpenBSD as a desktop environment – I’ve actually yet to really put it through its paces that way (although I did set up OpenBSD 3.0/Mac68k with WindowMaker a while back….).

Which one do I like the most?  Currently I find myself looking toward OpenSUSE 10.3 more and more – and loving to use it.  The new KDE menu is a pleasure to use, and I love the immense selection of RPMs (and I do like RPM as it is).

The fact that they split up the KDE RPMs seems ghastly to me – too many things to choose.  For example, KDE Office is available in all its little bits – as is KDE Toys, KDE Games, and whatever else.  Nicer just to choose to install KDE Toys or not… I’m not sure whether I like having KDE 3 as a base with all of the KDE 4 applications available – but it seems to work alright.

I’d like to install BeleniX next, but they’ve not updated their system yet – the last hard disk install was buggy. I’m waiting eagerly….

New operating system releases!

This is just amazing: did everybody coordinate this? Within the last three weeks or so, we’ve seen these releases come out:

Several of these were released on the same day, November 1.

What next? Am I really supposed to choose just one? Sigh. And I just installed OpenBSD 4.1 and Fedora 7, too – not to mention installing FreeBSD 6.2 not too long ago.

From all the talk, I’ll have to try Kubuntu again. So many systems, so little time.

I have been using OpenSUSE 10.3 (with KDE). I just love it – and I love the new menu format, too.

Update: Sigh. I should have known. Microsoft Windows Vista celebrated its 1st Anniversary on Nov. 8.

Marvell 8335 Chipset: The State of the Union

Previously I mentioned the Marvell Libertas 8335 wireless chipset. In researching further the Marvell chipsets, it turns out that some of the Marvell drivers (though not the 8335) even have problems with Windows Vista.

The Ubuntu Linux community seems to have some nice documentation on using the Marvell 8335 chipset (the Linux driver is called mrv8k), including specific instructions for the TRENDnet TEW-421PC. The blog My Favorite Ubuntu has some nice instructions specifically about using the PM150NXT08 Wireless Adapter by NEXXT with Ubuntu Edgy.

The One Laptop Per Child (OLPC) project stirred up some serious controversy when the project went with the Marvell Libertas chipset, resulting in a very unhappy letter from Theo deRaadt. The Jem Report has an article that explains most all sides fairly well. In short, using the Marvell chipset required signing of an NDA, which means that the information thus learned cannot be used by the open source community to build or enhance drivers for this chipset.

It turns out also that the drivers for (some?) Marvell products require the use of proprietary firmware; thus, even with an open source driver the system still requires proprietary products to operate.

However, in spite of the fact that Marvell is the bane of the open source platform, it turns out that it seems to be the darling of the commercial builders. When Netgear chose the Marvell platform, Marvell released a press release about the fact and generally seemed to strut shamelessly. The press release was widely reported; here is the report as seen in the EETimes.

The Linley Group (who?) went so far as to state (in 2006) that Marvell’s chipsets were the best 802.11g chipsets in the market. This, of course, comes from Marvell (as reported by the Wireless Broadband Exchange Magazine here). If you want to see more awards and press releases ad nauseum from Marvell, check out their web site.

My current recommendation about the Marvell chipsets and those products designed around them: avoid them and go with the (perhaps older) better supported chipsets from other companies.

Running Linux/UNIX in Tight Spaces

After trying to run a variety of systems, it becomes clear that certain kernels are much smaller than others. In the past, I’ve tried several different versions of small memory Linux and BSD.

It becomes clear that the BSD kernel is the smallest of the three major flavors, and can run where nothing else can. PicoBSD can run in places that floppy-based Linux distributions couldn’t, and there are other instances as well. In trying to get Linux or UNIX running on the Compaq Armada E500 (with 128M), it became obvious to me that BSD is smaller than the Linux kernel or the Solaris kernel. Solaris appears to be the largest – running Solaris in 512M of memory (with KDE) is almost (but not quite) usable. Trying to install Fedora Core 5 failed as 128M of memory wasn’t enough to install it. Solaris 8 did run in 128M, but it is two versions out of date, and not really usable in that nothing current is available for it.

FreeBSD 6 works in 128M without trouble, despite being the most current version – where as Fedora and Solaris cannot run in that amount of memory. I should say, too, that this is, in all cases, with an X session running – whether WindowMaker (low memory) or KDE or GNOME (more memory).

So, if things are tight, best to go with BSD – whether with FreeBSD, NetBSD, or OpenBSD. And do yourself a favor and run WindowMaker….