UNIX Administratosphere

Another book to read is The Humane Interface by Jef Raskin. This book is an easy read, very comprehendable and understandable.

When a system administrator writes a script, it behooves us to make it simple to use and simple to understand. If we write utilities for users, it is even more important to get the user interface right. Making the interface simple, understandable, and yet powerful can be daunting.

This book does an excellent job of introducing us to the challenges (and, indeed, the joys) of making the interface easy for normal human beings to use. This, in turn, will reduce the number of human errors that happen - human error is the number one cause of system failures. It will also introduce you to the fact that a lot of what passes for “difficult to use” is actually design failures in the interface.

The best documentation out there on OPIE focuses on using OPIE with FreeBSD. FreeBSD comes with OPIE as part of the core, and it works beautifully.

The FreeBSD Handbook contains a section on One-time Passwords (14.5) which discusses using OPIE, and how to use utilities associated with it.

The esteemed Dru Lavigne wrote excellent articles as well (way back in February of 2003!) about making OTP work in FreeBSD. The first was One-Time Passwords, and followed by PAM (which used OPIE access as an example).

There is no installation required, as all the appropriate bits already exist in the base install. To get started, follow this example with your own password:

$ opiepasswd -c
Only use this method from the console: NEVER from remote. If you are using
telnet, xterm, or a dial-in, type ^C now or exit with no password.
Then run opiepasswd without the -c parameter.
Using MD5 to compute responses.
Enter new secret pass phrase:
Again new secret pass phrase:
 
ID dgd OTP key is 499 xf4915
OTTO BRIM CAT PEN FAD PREEN
$

Now everything is set. However, the first password requested will be number 498: so let’s generate the key so we can record it:

$ opiekey 499 xf4915
Using the MD5 algorithm to compute response.
Reminder: Don’t use opiekey from telnet or dial-in sessions.
Enter secret pass phrase:
498: SLIP MAX ROT BLIP PIP FLIT
$

Note that this second step does not have to be done on the same machine. You do need to have your count (499 in the example) and the seed (xf4915 in the example). Combined with your secret password, you can generate your next password or passwords using any valid OTP password calculator.

Dru’s article on PAM discusses the conversion from Linux PAM to OpenPAM, and other things relevant to the introduction of FreeBSD 5.0. However, now with FreeBSD 6.3 out and FreeBSD 7 coming, most of what she discussed then is now well-tested and preconfigured. OPIE is built into PAM as she suggests (within the file /etc/pam.d/system file).

Now if you want to be forced to log in with OTP, touch the file .opiealways (note the leading dot) file in your home directory and it will be so.

There was also an interview done in June of 2007 in BSDTalk #117 (audio) which discussed OTP in depth. One interesting thing to note: FreeBSD uses OPIE, whereas NetBSD and OpenBSD both use S/Key for their implementations.

Checklists are useful for checking that you don’t miss anything in a repeated extended process. This can be anything from maintenance windows to database installations. It is not necessary that it must be an enterprise-wide checklist; checklists are useful for us as administrators as well.

To create an excellent checklist, follow these steps:

• Create a suitable title for each major step or category. When all the checklist items are done, then this category (or step) will be completed.
• Separate each section from the next with whitespace. This keeps items clear and separated so they won’t mix in your mind when you read them.
• Create a bar of some sort to highlight the title. This will further separate the various sections, and will make the title stand out.
• Create a list of all actions to perform. These are actual steps - actions to do - and not nebulous unspecified things to get done.
• Test the checklist. If this checklist will be used repeatedly, then try it out. Take notes as you use it. Since the checklist is best used on paper, use a paper version to take notes on and transfer the results to the actual list later.

Installing GRUB onto a FreeBSD system isn’t that hard - if you know how.

If you just run grub-install as root - which should normally work - you might see an error like this:

# grub-install hd0

GNU GRUB version 0.97 (640K lower / 3072K upper memory)

[ Minimal BASH-like line editing is supported. For the first word, TAB
lists possible command completions. Anywhere else TAB lists the possible
completions of a device/filename. ]
grub> root (hd0,1,a)
Filesystem type is ufs2, partition type 0xa5
grub> setup –stage2=/boot/grub/stage2 –prefix=/boot/grub (hd0)
Checking if “/boot/grub/stage1″ exists… yes
Checking if “/boot/grub/stage2″ exists… yes
Checking if “/boot/grub/ufs2_stage1_5″ exists… yes
Running “embed /boot/grub/ufs2_stage1_5 (hd0)”… failed (this is not fatal)
Running “embed /boot/grub/ufs2_stage1_5 (hd0,1,a)”… failed (this is not fatal)
Running “install –stage2=/boot/grub/stage2 /boot/grub/stage1 (hd0) /boot/grub/stage2 p /boot/grub/menu.lst “… failed

Error 29: Disk write error
grub> quit

The first step is to set a FreeBSD kernel variable:

sysctl kern.geom.debugflags=16

This will make the master boot record (MBR) writable, which is normally where the boot record is installed. Unless you do this, you will receive the error above.

Once the variable is set, the program grub-install should work fine with your chosen drive. The menu is in /boot/grub/menu.lst; here is a starter example for FreeBSD:

title FreeBSD
root (hd0,0,a)
kernel /boot/loader

The loader is the “kernel” in this case, as it will load the FreeBSD kernel anyway and it allows you the ability to drop into the boot console if you want.

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?

Gary Sims wrote an excellent and in-depth review of FreeNAS (a FreeBSD-based network attached storage system). His article details his experiences with FreeNAS, how it worked, where it (or he) failed, and other tips and tricks that he found as he went.

While FreeNAS appears to be the most popular (at least according to Google!) there are others out there, including OpenFiler (which is Linux-based).

A NAS basically is a dedicated file server that provides many different protocols to the clients and acts as an appliance. In some ways, this is no different than the historical file server - but in these cases, the NAS device is much more a turnkey solution with no other purpose. Many NAS systems support Windows file sharing, Macintosh file sharing, NFS, and a plethora of other protocols - all in order to make files available as much as possible. OpenFiler is one of these.

NAS devices were traditionally contrasted against SANs (storage area networks). The NAS provided a filesystem on the network; the SAN provides a block device on the network. This apparent sharp division of purposes does not exist in reality: some NAS systems also provide SAN resources as well.

Which - FreeNAS or OpenFiler - would I use? Can’t say - OpenFiler caught my eye first, but FreeNAS has the FreeBSD base. I’m liable to try both of them one of these days.

There are a number of books that a system administrator should be reading. In this new weekly series, I plan to cover specific books and review them and their importance to the system administrator.

Book One: Re-imagine! by Tom Peters.

This book covers many things about business and conducting business in the new century. The book itself is a marvel of disruptive and in-your-face design (which is just the way Tom wanted it).

Probably the most important concepts covered (in depth) are the fact that you are a “professional service firm” of one, and that the customer (not the shareholder) is king - that is, provide the best service possible even at a cost to the company or to the employees.

There are also a number of tutorials on how to keep environment variables set in screen sessions. Why does this matter? Because SSH relies on it - for SSH agent operation, as well as X forwarding. Thus, each of the articles solve a slightly different problem, but it all comes out to the same thing: getting the environment variables right.

Many of the tutorials start with this problem: one starts ssh-agent, then screen: now how do the sessions maintain the proper environment variables? This article by Charles Fry shows a way to craft a screen initialization script with the proper variables. This article suggests using a screen “wrapper”: run screen first, then ssh-agent, the screen again. The inner screen session then becomes the main session, and the outter session mainly holds the results of the ssh-agent run.

Some tutorials handle a different problem: one starts ssh-agent, then connects to another machine with ssh - then runs screen after that. That screen session will become “disconnected” from the ssh-agent forwarding scheme once you exit and connect to it from another machine. The environment variables are no longer valid. The basic solution is to overwrite the session environment variables with the current (and correct) version. Samat Jain has an article on this, and Sam Rowe also has an interesting article at deadman.org about the same thing.

On a different note, there is an excellent tutorial and overview of GNU screen at polishlinux.org. While it is from July of 2007, it remains up to date - I just don’t know why I haven’t seen it until now. If you haven’t started using screen, this is a good place to begin.

Of course, there is my book GNU Screen: A Comprehensive Introduction.

I can’t believe I haven’t mentioned the Core Linux distribution yet. It has been described as a Linux From Scratch version prebuilt with just enough to compile your favorite sources. Core Linux is not a distribution for the new Linux user; it is a distribution that is handcrafted by the user to do what the user wants. There is no packaging system; everything is done by compiling the sources onto the machine.

There was an article on the Core Linux forums recently which detailed one person’s experiences in installing Core Linux onto a USB stick in preparation for installation onto a EeePC. No word on how the installation went, but apparently booting from USB was perfect.

Using a distribution like Core Linux will give you an excellent education on how things work in Linux, and how to do things from the ground up. Using Linux From Scratch takes that one step further: starting with a Linux system, you compile everything - everything - and build your own Linux system starting from nothing.

Linux From Scratch takes a long time however, and can be quite challenging to get set up properly; Core Linux may be a better choice to start with. Both are excellent.

A few versions back, HP started including Veritas VxVM (Veritas Volume Manager) with HP-UX 11i. There was some consternation that VxVM was a third-party non-HP product, and that it would mean the demise of LVM.

However, now in HP-UX 11i v3 HP has turned the tables on Veritas (now Symantec) so to speak. In essence, this is another replay of the operating system vendor shooting down the third-party vendor.

In the past, HP-UX did not support load balancing on HP-UX with the native LVM disks; only VxVM supported multipathing with fail-over and load balancing. Now, in HP-UX 11i v3, the native drivers support full load balancing and failover with multipathing, and VxVM has been eviscerated: under 11i v3, VxVM’s multipathing DMP is put into straight-through mode (that is, no failover, no load balancing) and the new 11i native multipathing takes over.

When the disks are presented to HP-UX 11i v3 properly, the following will be output for the ioscan -m dsf command:

# ioscan -m dsf
Persistent DSF           Legacy DSF(s)
========================================
...
/dev/rdisk/disk16        /dev/rdsk/c7t0d0
                         /dev/rdsk/c6t0d0
/dev/rdisk/disk17        /dev/rdsk/c7t0d1
                         /dev/rdsk/c6t0d1
/dev/rdisk/disk18        /dev/rdsk/c7t0d2
                         /dev/rdsk/c6t0d2
/dev/rdisk/disk19        /dev/rdsk/c7t0d3
                         /dev/rdsk/c6t0d3
/dev/rdisk/disk20        /dev/rdsk/c7t0d4
                         /dev/rdsk/c6t0d4

With the proper multipathing in place, the “persistent DSFs” (DSFs are Device Special Files) are matched to multiple paths (which are reflected in the legacy DSFs). If you see this output from ioscan -m dsf, then multipathing is enabled for the disks as shown.

If ioscan -m dsf reports a syntax error, then you are not running on HP-UX 11i v3 - 11i v2 and below did not support the -m option.

It would appear that HP was serious about supporting LVM on HP-UX after all.