UNIX Administratosphere

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.

I mentioned previously that on my Mac Mini I am using a cellular connection for my Internet link (instead of dial-up). However, from time to time, the connection would get stuck (after dropping) in the “Disconnecting…” state in the graphical tools. There didn’t seem to be anything I could do to stop it. The system doesn’t have what I usually consider essential tools - ptrace, strace, ltrace. In any case, there is a good chance that all three could be Linux-specific commands, and this system is running Mac OS X 10.4 (Tiger).

Then I remembered gdb. Looking up the processes for pppd I found this:

$ ps auwx | grep ppp[.]*d
root 21475 0.0 0.1 28040 1204 cu. Ss+ 10:24AM 0:00.57 pppd serviceid F31F5F28-9986-489D-88F3-CFA56FF89443 controlled
$
$ sudo gdb -p 21475
Password:
GNU gdb 6.1-20040303 (Apple version gdb-384) (Mon Mar 21 00:05:26 GMT 2005)
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type “show copying” to see the conditions.
There is absolutely no warranty for GDB. Type “show warranty” for details.
This GDB was configured as “powerpc-apple-darwin”.
/private/var/log/21475: No such file or directory.
Attaching to process 21475.
Reading symbols for shared libraries . done
Reading symbols for shared libraries …………………………………………….. done
0×90032084 in wait4 ()
(gdb) step
Single stepping until exit from function wait4,
which has no line number information.
^C
Program received signal SIGINT, Interrupt.
0×90032088 in wait4 ()
(gdb) q
The program is running. Quit anyway (and detach it)? (y or n) y
Detaching from process 21475 thread 0xd03.
$

This tells me that the pppd daemon is inside a wait4() function (described in the wait(2) man page). This function is waiting for a child process to complete. So then, the next step is: what is this child process that pppd is waiting on?

$ ps alwwx | grep ppp[.]*d
0 21475 42 0 31 0 552328 1228 - Ss+ cu. 0:00.57 pppd serviceid F31F5F28-9986-489D-88F3-CFA56FF89443 controlled
$ ps alwwx | grep 21475
501 25310 25201 0 31 0 8780 8 - R+ p3 0:00.00 grep 21475
0 21475 42 0 31 0 552328 1228 - Ss+ cu. 0:00.57 pppd serviceid F31F5F28-9986-489D-88F3-CFA56FF89443 controlled
0 25131 21475 0 31 0 27688 740 - S+ cu. 0:00.02 /usr/libexec/CCLEngine -m 1 -l F31F5F28-9986-489D-88F3-CFA56FF89443 -f /Library/Modem Scripts/Nokia 3G Packet RB 460 -v -E -S 5 -L 120 -I Internet Connect -i file://localhost/System/Library/Extensions/PPPSerial.ppp/Contents/Resources/NetworkConnect.icns -C Cancel
$ sudo gdb -p 25131
GNU gdb 6.1-20040303 (Apple version gdb-384) (Mon Mar 21 00:05:26 GMT 2005)
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type “show copying” to see the conditions.
There is absolutely no warranty for GDB. Type “show warranty” for details.
This GDB was configured as “powerpc-apple-darwin”.
/private/var/log/25131: No such file or directory.
Attaching to process 25131.
Reading symbols for shared libraries . done
Reading symbols for shared libraries …….. done
0×90001b04 in ioctl ()
(gdb) s
Single stepping until exit from function ioctl,
which has no line number information.
^C
Program received signal SIGINT, Interrupt.
0×90001b04 in ioctl ()
(gdb) q
The program is running. Quit anyway (and detach it)? (y or n) y
Detaching from process 25131 thread 0×20b.
$

So…. the script is stuck in ioctl (described in ioctl(2)). A kill was not sufficient, but a kill -9 stopped it. After this, the graphical tools stopped reporting “Disconnecting…” and a reconnect was possible - and went cleanly.

One aside: note the first line:

grep ppp[.]*d

This matches “nothing” (as well as multiple characters) but does not match the grep command itself (which it would if the nonsense pattern were not included). Small thing, but can help especially in scripts that grep through the ps command output. Other patterns are usable here; the key is that the pattern will not match itself, will match nothing (empty string), and will not match anything which is present in the output.

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.