On Mon, 2006-06-26 at 22:56 +0100, Paul Howarth wrote:
> On Mon, 2006-06-26 at 12:47 -0500, Marc Schwartz (via MN) wrote:
<snip>
>>> Can you check that the dccproc being invoked by spamassassin is the one
>>> in /usr/local/bin and that its context type is dcc_client_exec_t?
>> dccproc only exists in two locations:
>>
>> /var/dcc/build/dcc/dccproc/dccproc
>>
>> and
>>
>> /usr/local/bin/dccproc
>>
>> The former is where dcc does it's build each night.
>>
>>
>> It was:
>>
>> user_u:object_r:bin_t
>>
>> I ran restorecon on it and now:
>>
>> system_u:object_r:dcc_client_exec_t
>>
>>
>> However, thinking that the build process might change the context, I
>> manually ran updatedcc via sudo from the CLI. Sure enough, the context
>> is back to:
>>
>> user_u:object_r:bin_t
>>
>> So the change in context will occur every night. :-(
>>
>> Should I add a restorecon to crontab after updatedcc runs?
> Yes.
Done. This takes place 10 minutes after updatedcc runs, in case there is
some delay in the download. I moved the pyzor update to 1:15 am and the
razor update stays at 1:20 am.
>> Also, there is some configuration info here:
>>
>>
http://www.rhyolite.com/anti-spam/dcc/dcc-tree/INSTALL.html
>>
>> where some settings (ie. UID) might be apropos here. If something makes
>> sense to change, let me know.
> It looks tricky. There's one script that both compiles and then installs
> the updated version. It only needs to be root to do the install, and
> would need changing to split the functionality.
Agreed. Without fundamentally changing the script, this would be
problematic.
I think a better updating option would be to get dcc into a third-party
repository and use the usual yum method to update the software.
Whilst it's not free software and hence unsuitable for Extras, I don't
think the license would prevent it being packaged somewhere else.
Paul.