UNIX Administratosphere

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.

SystemTap is one amazing piece of work - it is a programmer-friendy and admin-friendly interface to KProbes (which are included in the Linux 2.6 kernel).  When you compare its capabilities to what has gone before, it is truly amazing.  Here are some of the things you can do:

• Quantify disk accesses per disk per process (or per user)
• Quantify the number of context switches that are a result of time outs
• List all accesses to a particular file and the process that accessed it

This is only the tip of the iceberg. There is a wiki with more details, including “war stories.”  There is a language reference there as well.

There was an excellent article in Red Hat Magazine, “Instrumenting the Linux Kernel with SystemTap” by William Cohen.

One controversy that came up was that the initial impetus for creating SystemTap was to implement something like Sun’s DTrace for Solaris but under the GNU Public License.  Solaris and DTrace are licensed with Sun’s Common Development and Distribution License (CDDL), which many feel makes DTrace incompatible with the GPL-licensed Linux kernel.

Apparently, the CDDL is also incompatible with the BSD-licensed FreeBSD, as FreeBSD 7.0 will not have DTrace either.  There appears to be some licensing issues.

According to the Wikipedia entry on the CDDL, it was designed to be both GPL-incompatible and BSD-incompatible.  With regard to the GPL, the entry suggests that Sun never clarified why; as to the BSD, Sun did not want Solaris to wind up in proprietary products - which the BSD license allows.

On a brighter note, Eugene Teo was able to get the SystemTap tool to work on the Nokia N800.  The article seems to be behind a wall at LiveJournal; the article is still in Google’s cache.  However, it does requires some amazing convolutions:

• A kprobes-enabled kernel must be installed on the N800
• The SystemTap programs (like stap) must be installed on the N800
• Any traces must be cross-compiled on another host
• The kernel module thus created must be moved to the N800
• Once the kernel module is in place, then the trace can be done.

So every desired trace requires precross-compilation on a desktop (sigh)…  Oh, well.

There is even a GUI for SystemTap in the works.

Writing portable scripts for UNIX and Linux is fairly easy - Korn shell is everywhere, and ksh scripts work the same and have the same basic tools available (sed, awk, pipes, etc.).

What about writing portable scripts to work on UNIX, Linux, and OpenVMS? UNIX and Linux are similar enough that things will work across the different platforms - the same holds for the BSD platforms and for Windows with the Cygwin utilities.  But radically different platforms such as OpenVMS require a different approach.

The first thing I did in looking at OpenVMS was to search out the languages and utilities that were available.  HP offers a number of open source tools, and has Freeware CDROMs available as well. SAIC has a large OpenVMS archive, including the contents of the HP Freeware CDROMs.

Under OpenVMS, I found these languages available:

• Java (built-in)
• GNU awk
• Perl
• Perl/tk
• tcl/tk
• Python

I doubt that Java would be used for scripting purposes, but it is becoming ubiquitous and if it is well-known by the scripter, it is possible that it could be used.

However, the other (add-on) alternatives seem to be much more likely.  Perl, Python, GNU awk, and tcl have extensive capabilities, and with tk visual displays are possible.  My main choice would probably be Perl.

The next step is to make sure that any coding that is done is truly portable.  Perl, with its extensive documentation, includes documentation specifically for portability and for OpenVMS as well.

The Perl portability documentation goes into complete detail about the various points that may trip a programmer up; in short, several of the main points cover:

• Data representation (high-endian order? low-endian order? line terminator?)
• File path representation
• Character sets and encoding (including order)
• Time and date representation

The best thing to do is to following the guidelines in the Perl portability document (even if using other languages) and to then test the portable code on all systems affected. Only in extreme circumstances should code be written specifically to the target system and selected based on target OS type.  Better to make it portable at its core.

Traditionally, the root account (account 0) is not used for daily tasks.  This is widely known; however, this is the reason that root’s home directory was usually / (the root directory) as there was no need for .profile, .login, .Mail, and so forth.  The root account is even created under MacOS X with a locked-down password (that is, there is no valid password for root, making it impossible to log in as root).

However, this is most certainly not the case today - and more and more administrators use the root account for many tasks. One common problem is the problem of someone wanting to change the root shell - and then breaking the startup process since some scripts would assume that the shell is the Bourne shell.  This was more of a problem under BSD since the standard BSD shell was the C shell, and the startup scripts usually assumed the Bourne shell (which is completely incompatible with the C shell).  The toor account (that is, root spelled backwards) was created for this purpose: a person can log in as toor and have the C shell (csh), but not affect the standard startup process.  A toor user would still have the userid zero (0) but would for all intents and purposes be the root user.

This would also lead to the possible creation of a specific home directory for the toor user.

In MacOS X, the root user is locked down and no login is possible as root.  To access root, the sudo utility must be used as the admin user (which should be the user that installed MacOS X).

The wheel group is also part of this process; using the wheel group can expand the capabilities of some users in order to further reduce the need to actually use the root account as a shell account.

Thus, you can see that there is really no reason to use the root account.  But is that going to stop us? Perhaps it should…

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….

When you use Synergy, it connects one computer (and desktop) to another. Your mouse will flow seamlessly from one desktop to the next. A number of desktops can be combined, although programs remain confined to their desktops.

Synergy is different from multiscreen desktops - a standard multiscreen desktop stretches a single operating system environment across multiple screens or displays. In most normal cases, this is what would be preferred for normal users. However, if you are using multiple systems for different purposes, you can concatenate separate displays together.

When you move your mouse from one desktop (Mac OS X, for instance) to another, it is like moving from one computer to the next. In some ways, it is like a multi-screen software KVM (Keyboard-Video-Mouse) switch. The server runs on the system with the keyboard and mouse, and the clients run on other systems. Each system has its own monitor, and can be placed (virtually) anywhere through proper configuration of the server. For example, the screens could be placed one on top of the other, or side by side. If one display is disconnected, then it will be skipped. For example, if there are three screens in a row, and the middle one loses connection to the server, then it will be skipped over as the mouse moves from one system to the other.

Recently, I had the server running on Mac OS X, a client on Fedora Core 5, and a client under Solaris 8. The mouse could then be moved to the left side of the Mac OS X display, and it would appear on the right on the Fedora Core 5 display. Continuing to move the mouse, it would eventually wind up on the Solaris 8 display. The only drawbacks are the network delay and differing mouse speeds. I’ve grown addicted to it - try it today!

I was asked this question recently. Everyone likely has an answer: Red Hat Linux, Debian GNU/Linux, Solaris… My answer surprised the questioner: UNIX and UNIX-workalikes. This includes FreeBSD… and Red Hat… and Solaris… and HP-UX… and AIX… and so forth. When I first became interested in UNIX, not one of the aforementioned products existed. First UNIX system I got my hands on briefly was Eunice (look it up and the next (a few years later) was Microport System V (for the IBM AT).

Perhaps you might think Solaris is better than Linux - or NetBSD is better than OpenBSD. I suggest it doesn’t matter. Each UNIX (or UNIX-like) environment has its pluses and minuses. Individual choices are personal and enterprise choices are practical - in either case, which is truly better doesn’t matter.

If your enterprise is using Oracle, for example, the choice of which UNIX system you use is dramatically reduced: which system will Oracle support? You won’t be using Oracle on FreeBSD unless you forgo the Oracle maintenance contract. Choices like this continually appear in the enterprise. Perhaps the new version of Red Hat Enterprise Linux has everything you want - but Oracle doesn’t yet support that version.

Alternately, which system you use for your own desktop is a personal choice. Which one is “better” is which one feels better to you. UNIX is, at its heart, unified - that is, it is a single environment - but it provides a wide choice of user interfaces, user programs, and even technical items such as filesystems and virtual memory management schemes. Use whichever one seems better.

What do I use on my personal desktop? Mac OS X. However, in line with the ideas posited above, I’ve just expanded my “desktop” with Synergy, linking my “other” desktop (first Fedora Core 5, now BeleniX with OpenSolaris core) to my Mac OS X desktop. More about Synergy later.

So next time someone tells you what their favorite operating environment is - why not find out what it is they’re so excited about? You might find something exciting yourself.

The wheel group is, perhaps, not widely used today, or is seen as “archaic” and irrelevant. Nothing could be further from the truth.

The wheel group is a group which limits the number of people who are able to su to root. This usually consists of a group named “wheel” and a set of users that are permitted to use the utility ’su’ in order to change to root.

Many systems, especially either commercial systems or Linux systems, come without wheel groups configured and implemented. At least one Linux distribution, comes with wheel groups preconfigured but not active. However, all or nearly all BSD based systems will come with the wheel group installed and set up.

However, at its simplest, a wheel group implementation requires no special set up. The basic set up, as it was in the beginning, was to do the following:

1. Create a “wheel” group in /etc/groups
2. Change the permissions of the “su” command so that only those in the “wheel” group may run it.

That’s all there is to it. Many su implementations, however, added internal support for the wheel group, perhaps with logs kept and a more informative refusal message explaining why su would not run (for those not in the wheel group).

Perhaps one reason that the wheel group is not widely used may have something to do with the GNU project. The GNU implementation of su has this in its info page:

Why GNU `su' does not support the `wheel' group
===============================================

   (This section is by Richard Stallman.)

   Sometimes a few of the users try to hold total power over all the
rest.  For example, in 1984, a few users at the MIT AI lab decided to
seize power by changing the operator password on the Twenex system and
keeping it secret from everyone else.  (I was able to thwart this coup
and give power back to the users by patching the kernel, but I wouldn't
know how to do that in Unix.)

   However, occasionally the rulers do tell someone.  Under the usual
`su' mechanism, once someone learns the root password who sympathizes
with the ordinary users, he or she can tell the rest.  The "wheel
group" feature would make this impossible, and thus cement the power of
the rulers.

   I'm on the side of the masses, not that of the rulers.  If you are
used to supporting the bosses and sysadmins in whatever they do, you
might find this idea strange at first.

Is it any wonder that GNU/Linux systems don’t enable the wheel group by default? FreeBSD, however, does use the wheel group by default - as does OpenBSD and NetBSD.