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 [EMAIL PROTECTED] to [EMAIL PROTECTED] >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