UNIX Administratosphere

If you wish to examine a runaway program outside of its element, you may choose to use the utility gcore. This utility is found in Solaris, Linux, and HP-UX, and perhaps others. The program syntax is:

gcore [ -o corename ] pid

The pid is the process id of the process to dump core, and the corename is the base of the filename to use for the core dump - the full name is the base name plus period (”.”) and the process id number. The default is to use “core“.

HP-UX systems will accept multiple process ids instead of just one. Solaris has several additional flags (as well as multiple pids). The additional Solaris flags won’t be covered here.

Once core has been dumped, the program continues operation; it does not stop. Thus, gcore is especially useful for taking a snapshot of a running process.

For example, consider a program with the process id 6674:

gcore 6674

This command generates a core file in the current directory with the name “core.6674“. This file then can be read by the GNU debugger gdb. Solaris also provides the dbx(1), mdb(1), and pstack(1) utilities. HP-UX provides gdb as well as the HP adb(1) utility. Both Solaris and HP-UX provide a core management utility coreadm(1m) - which is a topic for another day.

This article has an excellent description of working with core files in Solaris.

Well, it turned out that installing OPIE went smoother once I figured out what was causing the RPM rebuild to fail.

I took the source RPM from OpenSUSE, and installed it onto the Fedora system:

rpm -ivh opie-2.4-630.src.rpm

This installs the files in their appropriate locations in the RPM build tree. In Red Hat distributions, this means /usr/src/redhat: the spec file goes into /usr/src/redhat/SPECS, and the sources and patches go into /usr/src/redhat/SOURCES.

Then I had to remove a line from the spec file (opie.spec) that read:

%debug_package

Otherwise, the Fedora RPM suite complained thusly when built using rpmbuild:

error: Package already exists: %package debuginfo

Building the binary RPM consists of:

rpmbuild /usr/src/redhat/SPECS/opie.spec

The RPMs will be created in RPMS/i386.

Installing the RPMs is then very straightforward:

rpm -Uvh opie-2.4-630.i386.rpm

These steps bring us to the point where we now have opie available (and installed as an RPM). The rest is configuring opie. In the file /etc/pam.d/system-auth, add a line under the line that mentions pam_unix.so:

auth sufficient pam_opie.so use_first_pass

This line adds support for one-time passwords during logins - including most all forms of logins. However, some login programs do not handle the extra output and requirements well. KDM (related to XDM) perhaps does not handle it the best: a message is put up, and then it goes away without any indication that the password request has changed.

In any case, to support a user with OTP requires initializing their OTP key. This is done with:

opiepasswd -c user

This initializes the password and OTP for the specified user. This command should only be used in a secure environment (such as over SSH or on the system console). It will ask for a new password to create (only needed for a few things, but important) and then generates your secret password (along with the sequence number and the seed). All three of these things will be needed when using OTP calculators. Remember that your secret password is just like any other normal password: that is, it must be kept secret. The sequence number and seed are not enough to get in, and the generated OTP are not enough either (though they should also be kept secret).

It is possible to generate a list of the next series of OTP passwords to use; for example:

$ opiekey -n 5 -5 499 my9999
Using the MD5 algorithm to compute response.
Reminder: Don’t use opiekey from telnet or dial-in sessions.
Enter secret pass phrase:
495: KAY TRY GLOM NOVA CALF KIM
496: OVAL JADE RUNT LATE MIT JAKE
497: MYRA COED LIND TO GREY FIG
498: NESS WAKE BLOC COAT GAIT ROWE
499: CLAW GAGE HOST MARK FAIN PAP

However, do not do this over an insecure line - such as from telnet, xterm, rsh, and so forth - as your secret pass phrase will be sent in the clear. Whenever using an OTP password calculator, make sure that your password is not seen by others, whether on the wire or in person: again, it is just like a regular password and should be treated as such. The generated passwords should also be kept secret; however, during use secrecy is not required. That’s because as soon as it is typed in, it is no longer valid.

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.

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

• Ubunutu 7.10 Gutsy Gibbon (and Kubuntu, Edubuntu, Xubuntu, et al)
• OpenBSD 4.2
• Fedora 8
• Red Hat Enterprise 5.1
• OpenVMS 8.3-1H1
• FreeBSD 7 Beta 2
• FreeBSD 6.3 Beta 1
• OpenSUSE 10.3
• Macintosh OS X 10.5
• NetBSD 4.0 RC3
• AIX 6.1

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.

My post on the importance and methods of wheel groups remains popular. I though I would go into various UNIX variants and detail specifically how to activate wheel groups.

Today, the discussion is around Red Hat Linux (speaking generally). The test system was running Fedora Core 5; however, this area of Red Hat has not changed in quite some time, so it is likely to be the same in Fedora 7 and so forth.

First, make sure there is a wheel group in the /etc/group file. On Fedora Core 5, there is:

wheel:x:10:root

If this line does not exist, add it.

Of course, you must put users that you want to be admins into the wheel group. To do this, add the user to the end of the wheel group line. This will make the wheel group a secondary group; I don’t know if that will make a difference today, but it might somewhere.

Second, change into the /etc/pam.d directory, and edit the file su. This file controls the access to the program su and modifies its behaviors during the authentication process. The change will modify the access so that only those in the wheel group have access to the program su.

Find these lines in /etc/pam.d/su:

# Uncomment the following line to require a user to be in the “wheel” group.
#auth required pam_wheel.so use_uid

And change them (as suggested) to this:

# Uncomment the following line to require a user to be in the “wheel” group.
auth required pam_wheel.so use_uid

This access change is not necessarily limited to the su command, but no other command has normally been included in the past. If there are other commands that only those in the wheel group should be able to access, then this line could be put into their PAM configuration (in the right place).

Note that editing PAM files could very easily lock you out of your machine completely; thus do not take editing PAM files (in /etc/pam.d) lightly. The Red Hat authored wheel group modification is simple and easy; other changes you make may not be.

Then, expand the permissions in sudo to account for those with wheel permissions. Edit the configuration file with visudo and change these lines:

# Uncomment to allow people in group wheel to run all commands
# %wheel ALL=(ALL) ALL

To this (as recommended):

# Uncomment to allow people in group wheel to run all commands
%wheel ALL=(ALL) ALL

This will allow anyone in the wheel group to execute commands using sudo (rather than having to add each person one by one). It would also allow anyone this sort of access on any machine that they have wheel group membership.

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.