Some of you will find this amusing. I didn't, but then I was in the
middle of it :-).
You may have noticed that I've answered questions about amcheck reporting
"selfcheck request timed out" once or twice on this mailing list :-).
It almost always involves some kind of configuration error on the part
of the installer, although the exact details vary widely.
So I'm setting up my own home machines the other day, running Solaris
2.8-x86 with kernel auditing (BSM) enabled. I get to the first amcheck
and there's the dreaded error. Grrrr. You'd think the Amanda code
would know better than to mess with me by this time.
So I look and I look and I look and *nothing* is wrong. Seriously.
Really :-).
To summarize a *very* long debugging session:
* The "standard" 7.6 version of TCP wrappers is broken w.r.t. Solaris 8.
It has to do with how IPv6 is processed (even if you don't have it
turned on). You can get a corrected version, by the master Casper
Dik, from:
ftp://ftp.porcupine.org/pub/security/tcp_wrappers_7.6-ipv6.1.tar.gz
The symptom was requests being rejected and being logged as from
address 0.0.0.0.
* With BSM enabled (after you run "bsmconv"), inetd *refuses* to run
anything as a user other than root. Grrrrr.
The symptom in /var/adm/messages was "inetd ... tcpd: Hangup
It turns out there are multiple bugs here (sigh). First, the "Hangup"
is a reporting problem inside inetd (it's been sent in as a bug to
Sun multiple times already). The child process is doing an "exit(1)"
and the parent is treating the "1" as a signal number (which happens
to be "Hangup") instead of an exit code. It never even got to the
point of running tcpd or amandad -- they are both completely innocent
in all this.
The second bug is an invalid argument error being reported by the
audit routines (who wrote it to stderr and then did an lseek(0)
on stdin, which is the incoming connection -- bugs layered on bugs
layered on more bugs) having to do with trying to start the service
as "backup" (in my case) instead of "root".
I could not find any documentation that would provide a resolution
for this or even say it was expected behavior. In fact, I have this
exact same setup on several 2.6 machines and they do *not* have the
problem, which makes me think it's a bug rather than a feature.
Now the good news. My knee-jerk reaction (after I calmed down from
tracking multiple OS bugs and not doing the Amanda coding I wanted to
work on) was that it was a horrible thing to require me to run amandad
as root. However, it really isn't (which was news to me).
At the very beginning of the amandad code, it checks to see if it is
running as root. If it is, it changes to run as whatever user you set
with --with-user. This only happens if you also have --with-force-uid
turned on, but that's the default.
So setting up the inetd line to run amandad as root instead of the
Amanda user is not terrible. In fact, it forces amandad (and amindexd
and amidxtaped) run as the Amanda user.
This (BSM and Solaris 2.8) has shown up on the list a few times (more than
I remembered when I searched) and I've Cc'd the various people involved
in case it helps. As I read through those postings, almost everything
I rediscovered the hard way had already been figured out. My apologies
for not helping more the first time around -- I just didn't "get it".
John R. Jackson, Technical Software Specialist, [EMAIL PROTECTED]
