UNIX Administratosphere

How much memory is in this machine?

It would seem that answering this question ought to be easy; it is - but every system has the answer in a different place. Most put an answer of some sort into kernel messages reported by dmesg (AIX apparently does not).

Most systems have a program for system inventory which reports a variety of things, including memory.

Rather than go into great detail about each one, we’ll just put these out there for all of you to reference. Each environment has multiple commands that give available memory; each command is listed below.

Without further ado, here are a few answers to this burning question:

Solaris

1. dmesg | grep mem
2. prtdiag | grep Memory
3. prtconf -v | grep Memory

AIX

1. bootinfo -r
2. lsattr -E1 sys0 -a realmem
3. getconf REAL_MEMORY

HPUX

1. dmesg | grep Physical
2. /opt/ignite/bin/print_manifest | grep Memory
3. machinfo | grep Memory

Linux

1. dmesg | grep Memory
2. grep -i memtotal /proc/meminfo
3. free

OpenVMS

1. show mem /page

Update:

FreeBSD

1. dmesg | grep memory
2. grep memory /var/run/dmesg.boot
3. sysctl -a | grep mem

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.

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.