2005-12-31
Notes on getting a Solaris hardware inventory
Being able to find out what hardware is in a random machine is one of those things you don't think about very much until you inherit responsibility for a bunch of machines that you didn't build yourself.
The best hardware inventory program I've used is SGI's hinv
(although it doesn't have enough disk information). Linux has decent
hardware inventory support, but not bundled into a single command; you
have to look through a bunch of /proc files and know a few commands
like lspci. Unfortunately, Solaris is less friendly.
The old-fashioned way to get hardware information is to look at the
kernel's boot messages; on Solaris this is in syslog or via dmesg.
However, these logs get aged away if the system has been up for a
while. (I've been known to arrange for kernel syslog messages to never
expire, but I haven't set that up on my Solaris systems yet.)
The best program seems to be prtdiag, which gives CPU, memory, and
some hardware slot information (and works for non-root users, always a
bonus). There's also prtconf and a number of others, but they don't
seem to give much additional useful information about hardware.
The names of stuff in /devices has a some information, but I suspect
a good familiarity with Solaris device driver names is needed for best
results. (Solaris /proc is for processes only, so there is nothing
like Linux's collection of informative files.)
(People seem to use Magnicomp's sysinfo a fair bit, but it's
commercial software (with a 30 day free trial), and binary packages on
systems without real package managers make me twitchy. And its
installer has glitches that don't inspire confidence.)
2005-12-09
A surprising hazard of running as root all the time
We have some machines that are 'no user-operable parts inside'
setups; as part of that, they have no user logins, just root. (Yes,
yes, running as root all the time is bad, but on these boxes almost
all we'd ever do with a plain login is su to root.)
I'm attuned to all of the regular hazards of this, but today I
stumbled over a new one: how long it takes to notice that /var had
accidentally wound up mode 0750 (and owned by a group that didn't have
hardly anything in it) on a Solaris 2.4 machine.
Of course, root doesn't get permission denied messages, and most of
the obvious things were running as root and kept on working. About the
only sign was a large collection of files called things like
'mailAAAa00087' scribbled in /var/tmp. It turned out that these
files were complaints from cron about being unable to run lp cron
jobs because it couldn't change to lp's home directory, and bounce
messages talking about 'lp... Can't create output'.
So I looked at lp's home directory, /usr/spool/lp, which looked
perfectly fine and I could even cd into it as root. Only when I
did 'su lp' and tried it did I get a 'permission denied' error and
started backtracking to discover the /var permissions problem.
Sidebar: so how did it happen?
What I think happened is that someone built a tar file of a
/var/named directory they wanted to move around, but instead of
tarring up the directory, they cd'd into the directory and tared up
'.'. Then they moved it to this machine and accidentally untarred it
in /var instead of making a /var/named directory and untarring it
there. As part of unpacking, tar dutifully set the permissions on
all of the files and directories in the tarball, including '.'.
So the moral is: tarfiles that include . are annoying and
dangerous in more than one way.