UNIX Administratosphere

In the past, the z/Series has been known for its virtualization of Linux servers (over 10,000 possible!). Now, someone is showing OpenSolaris running on z/Series at the Gartner Data Center Conference in Las Vegas. There is an excellent write-up from the Mainframe blog, and another post from Marc Hamilton.

There is also an excellent open source IBM zSeries emulator called Hercules which can run Linux, MVS, DOS/VSE and others - and now, soon, OpenSolaris.

There is a very interesting speech given at Linuxworld by Guru Vasudeva from Nationwide about how his company implemented virtual Linux machines on IBM zSeries with z/VM.

When I first saw this (from IBM’s web site) I thought it was laugh out loud funny - and it still is. It also gives a hint at the power of the IBM z/Series, and shows one of the reasons I’m excited about the power one of these has.

I just love the deadpan Joe Friday responses from the cops, and some of the quotes:

• “Could it be an inside job? We’re inside, right?”
• “I need my pills!”
• “What’s a server?”

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

Sun decided to put CIFS support directly into the Solaris kernel instead of using SAMBA. Serverwatch reported on it, as did TechRepublic.

This sounds like a good idea: put support into the kernel where it is faster and has access to more of the insides of the kernel (rather than going through interfaces).  It is like programming on the bare metal instead of using the standard toolbox calls (or API).

However, the downside is not often reported: this will make the kernel even larger and opens up security risks as well.  I tend more to believe in the small kernel more than anything, and Solaris already appears to be one of the largest kernels in the open source arena.

Time will tell whether this was a good idea or not.

Recently, I had the chance to get a book that described how to make OpenVMS work with Linux.  Unfortunately, the entire book was 1) a list of screen-shots, and 2) about how to get OpenVMS 7 to act like (or interact with) Red Hat 7.

I was hoping for more details, and so on.  I was also hoping for documentation on how to get Linux to support OpenVMS networking and data and so forth.  The biggest project in this area is the Linux DECnet project, which wasn’t mentioned even once.

Well…. I went looking.  I’m not a OpenVMS wizard (yet!) but there are many tools that seem to be quite nice, though many of them aren’t maintained any longer:

• CDROMS: an application (written by a fellow at SUSE!) to allow reading OpenVMS ODF CDs on Linux
• A DECnet network bridge
• A KDE IO slave for DECnet
• An authentication module for Linux that allows VMS users to use their VMS passwords on the Linux system

Support for DECnet is now included in the kernel, though the Linux DECnet Project still has some excellent documentation like this DECnet FAQ.  There is a nice (though old) article about DECnet from Linux Journal.

Remember: I can’t vouch for any of these - it just seemed to me that projects like these are not likely to be known, and I wanted to get them out there.

One aside: it turns out there is a shop that provides VAX emulators, PDP-11 emulators, and Alpha emulators for running OpenVMS on Windows: Salem Automation Incorporated is probably best known for CHARON-VAX, though they have all of the others as well. There is a personal version of the CHARON Alpha Emulator.  Again, I can’t vouch for them, but I do know that CHARON-VAX in the past seems to have been quite popular and well respected - but your experience may vary.

It appears from this article by ITWire that the Asus EeePC may be in violation of the GPL.  The GPL is the copyright that covers the Linux kernel and specifies the rights and responsibilities given to the receiver of the copyrighted product (the kernel in this case).

Turns out that Asus has utilized the kernel with some modifications but has not released any of the source code - a direct violation of the GPL.  And with the Software Freedom Law Center (SFLC) filing new lawsuits on behalf of busybox (another GPL-licensed product) after resolving the last one to the benefit of busybox, I can’t help but imagine that Asus will tread carefully and will negotiate.  We’ll see.

When I worked for a cabinetmaker for a number of months, I asked him about the various tools available and about which ones he used. One thing he said a lot was “that brand is okay, but in a production environment it won’t last.” That is, the cabinetmaking shop would go through the lightweight tools quickly and was different than a home woodworker.

So it is in system administration. When you have users counting on a system to be up, even a planned system outage is going to be extremely unpleasant and costly. Add up the cost of every worker not being productive, projects delayed, overtime paid, and so on. If the planned outage then becomes even longer than expected, you can see the costs begin to add up.

Thus, there are a number of things to keep in mind that would not matter in a non-production environment - an environment where a system outage means you don’t get to play Marble Blast Gold for a couple of hours. The details of planning an outage of a production system can make up an entire book, but here are some things to keep in mind:

1. Communicate benefits. Set up meetings and show the users the benefit they will receive from the system outage. Don’t tell them that they’ll get more memory: tell them the system will be faster and respond quicker. Don’t tell them there’ll be more disk space: tell them they’ll be able to store more data.
2. Plan for failure. Think of this as disaster recovery planning for the project - or as welcoming Murphy into your plans. Anything that can go wrong will - so plan ahead as to what you will do when it does.
3. Minimize downtime. In whatever ways you can minimize downtime means cost savings to the company - cost savings that they can pass on to your or the customer. It also makes the higher-ups happy, which is always a good thing.
4. Test - then test some more - then test again. Make trial runs and see if it works. Make detailed plans of what to do and what might happen. Test to see if things worked properly - then test again.
5. Make backups! Backup the system just before the major change (just in case) and then back it up again just afterwards. Set aside these tapes - and in the meantime, keep the regular daily backup rotation going. Then if you have to roll back, you can.
6. Make checklists. Sure, you didn’t miss anything the first time - but what about the second time? Can you replicate every step all the way through, without missing any and without doing anything different? Did you test everything or did you miss one? Make checklists - as David Allen would say, “Get it out of your mind!” (he’s right).
7. Organize a schedule. When will the system be down? Let everybody know and discuss how long. Agree on a specific day and time.
8. Decide on a pass-fail point. This could be thought of as a “point of no return” - if things are not going well or are not going according to schedule, what is the last moment (or last step) that you can successfully turn back and restore services as planned? Have one of these and stick to it. When that point is reached, determine whether there is room for error and whether everything is going well - or whether you must turn back.

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.

The nixCraft blog has an article about a very interesting map of the IPv4 address space from the Measurement Factory as part of the RouteViews project. The most recent map looks like this:

The map is very detailed (the above image is only a small version) and is available from CafePress as a full-size poster.

The map shows the IPv4 space as understood by the BGP routing protocol. The black areas are unroutable (at least from the Measurement Factory’s location at the University of Oregon) and the gray areas are either reserved or unallocated space.

Turns out there is a lot of things to watch out for!

I recently read this blog post on Steve Tobak’s blog “Train Wreck” over at CNet. Turns out there is a lot of legal liability (ouch) that can arise from posting. A most interesting source of information is the Electronic Frontier Foundation’s Bloggers page (with a Legal Handbook to boot).

Reporters without Borders has a handbook, too: Handbook for Bloggers and Cyber-Dissidents.  (Their entry page also has links to other languages as well - this international organization is actually French).

If you value digital rights, I’d recommend a donation or two to the Electronic Frontier Foundation.

I’m surprised how many people never think to do this…. but it makes it quite easy.

If you need a large text file, perhaps with 1,000s of lines (or even bigger) - just use doubling to your advantage! For example, create 10 lines. Then use vi (or other editor) to copy the entire file to itself - now 20 lines. If you remember how a geometric progression goes, you’ll have your 1,000s of lines rather fast:

1. 10 lines…
2. 20 lines…
3. 40 lines…
4. 80 lines…
5. 160 lines…
6. 320 lines…
7. 640 lines…
8. 1280 lines…
9. 2560 lines…
10. 10240 lines…

Ten steps and we’re at 10,000+ lines. In the right editor (vi, emacs, etc.) this could be a macro for even faster doubling. This doubling could also be used at the command line:

cat file.txt >> file.txt

Combined with shell history, that should double nicely - though using an editor would be more efficient (fewer disk reads and writes).

When writing code, often programmers will want to set things off with a line of asterisks, hash marks, dashes, or equals signs. Since I use vi, I like to type in five characters, then copy those five into 10, then copy those 10 and place the result three times. There you have 40 characters just like that.

If only a certain number of characters is needed, use dd:

dd if=/dev/random of=myfile.dat bs=1024 count=10

With this command (and bs=1024), the count is in kilobytes. Thus, the example will create a 10K file. Using the Korn shell, one can use this command to get megabytes:

dd if=/dev/random of=myfile.dat bs=$(( 1024 * 1024 )) count=100

This command will create a 100M file (since bs=1048576 and count=100).

If you want files filled with nulls, just substitute /dev/null for /dev/random in the previous commands.

You could use a word dictionary for words, or a Markov chain for pseudo-prose. In any case, if you only want a certain size, do this:

~/bin/datasource | dd if=- of=myfile.dat bs=$(( 1024 * 1024 )) count=100

This will give you a 100M file of whatever it is your datasource is pumping out.