Greetings;

After last nights run, I thought I'd see if it was using the new versions of 
things, but the only routine of those that do report in their debug files 
what version they are, is the runtar I copied out 
of /usr/local/libexec/amanda/runtar and put in /usr/local/libexec.

Everything else that reports its version in the debug files, is still 
reporting its version 2.5.2p1.

Duh...  Just remembered.  One thing I didn't do after editing the paths for 
the 3 items in /etc/xinetd.d/amanda, is restart xinetd.  Now that has been 
done.  Now, amcheck says it can't find amandates in the new location, so I 
moved that to the new location & now amcheck is happy again.  So that must 
have been it, but we'll check the logfiles again tomorrow morning.  Damn its 
hell to have CRS like this. :)

I'm hesitant to clean out the old stuff in /usr/local/libexec, but will once 
all the reported versions are correct.

There was quite a list of routines that do not report in the *.debug logfile, 
or at least that version did not report, their internal version.  Those that 
did not:

amcheck
amcheckdump
amlabel
amlogroll
amreport
chunker
driver
dumper
taper

It might be helpfull if they did have a sign-in of their version at the top of 
the generated *.debug logfile.

Also, I'm seeing an selinux denial advisory on screen, naming procmail, for 
everytime I think amanda is trying to send me an email.  I do the email 
activities here as root, but kmail sucks from both the root account and from 
the gene account, and I have changed the Mailto: address from root@localhost 
to gene@localhost.

>From setroubleshoot:
SUMMARY
SELinux is preventing /usr/bin/procmail (procmail_t) "search" to (var_log_t).

Detailed Description
SELinux denied access requested by /usr/bin/procmail. It is not expected that 
this access is required by /usr/bin/procmail and this access may signal an 
intrusion attempt. It is also possible that the specific version or 
configuration of the application is causing it to require additional access.

Allowing Access
Sometimes labeling problems can cause SELinux denials. You could try to 
restore the default system file context for , restorecon -v If this does not 
work, there is currently no automatic way to allow this access. Instead, you 
can generate a local policy module to allow this access - see FAQ Or you can 
disable SELinux protection altogether. Disabling SELinux protection is not 
recommended. Please file a bug report against this package.

Additional Information
Source Context:  system_u:system_r:procmail_t:s0
Target Context:  system_u:object_r:var_log_t:s0
Target Objects:  None [ dir ]
Affected RPM Packages:  procmail-3.22-20.fc8 [application]
Policy RPM:  selinux-policy-3.0.8-74.fc8Selinux 
Enabled:  True
Policy Type:  targeted
MLS Enabled:  True
Enforcing Mode:  Enforcing
Plugin Name:  plugins.catchall_file
Host Name:  coyote.coyote.den
Platform:  Linux coyote.coyote.den 2.6.24-rc7 #1 SMP Mon Jan 14 10:00:40 EST 
2008 i686 athlon
Alert Count:  26
First Seen:  Wed 09 Jan 2008 05:09:14 AM EST
Last Seen:  Wed 16 Jan 2008 05:09:15 AM EST
Local ID:  bfec6c3c-7d3b-47f7-9174-a2251b12534a
Line Numbers:  
Raw Audit Messages :avc: denied { search } for comm=procmail dev=dm-0 egid=500 
euid=500 exe=/usr/bin/procmail exit=-13 fsgid=500 fsuid=500 gid=500 items=0 
name=log pid=15219 scontext=system_u:system_r:procmail_t:s0 sgid=0 
subj=system_u:system_r:procmail_t:s0 suid=500 tclass=dir 
tcontext=system_u:object_r:var_log_t:s0 tty=(none) uid=500 

So I'm going to send this part to the selinux list also.

-- 
Cheers, Gene
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Luck can't last a lifetime, unless you die young.
                -- Russell Banks