Quinn Comendant wrote:
> On Thu, 25 Jan 2007 19:22:30 -0700, Eric "Shubes" wrote:
>>> %{qdir}/supervise/spamd/run
>> I don't think of this as a configuration file. [...]
>
> It's not really a "configuration file" but because it is something that might
> be fine-tuned there is a strong advantage to adding the %config(noreplace)
> flag in the rpm spec. By doing so we only ensure that upgrades will not
> overwrite this file if it is changed. The drawback is that if this file *is*
> modified as in a new version, the new copy will not be installed immediately,
> instead it will be installed in the same location with a .rpmnew extension
> (and a message printed to screen during install). The user will then need to
> compare their modified file (run) with the .rpmnew file (run.rpmnew). But
> this gives them the chance to merge the upgrade changes with their own
> modifications.
Yes, it's not really a configuration file, yet it contains configuration
data. That is the crux of the problem as I see it. I believe that the proper
solution is to remove the configuration components from the file and put
them where they belong. Making this file a config(noreplace) type is a short
term quick fix, that will create problems in the long term. For instance,
what happens when there's a change to the run file that is required for
proper operation (however unlikely that may be)? I suppose for that release
it'll need to be an rpmsave (and another change to the spec file).
>> As recently discussed on the
>> this list, I think it'd be good if the toaster had
>> /var/qmail/control/supervise/${service}/concurrent (or some such) control
>> files where tailoring of tcpserver parameters would be specified. These
>> control files, when present, should then be specified as %config(noreplace).
>> In the case of spamd, the -L switch should be tailorable. So there might be
>> a /var/qmail/control/supervise/spamd/switches file, which would contain
>> "-L", and the corresponding run file would include in the exec command line
>> if the "switches" file exists.
>
> I think that's really too much complexity and it makes it harder for
> everybody. How many control files would be needed to customize spamd the way
> I'm running it, which is:
>
> exec /usr/bin/spamd -q -x -u vpopmail -s stderr -P -m 15 --min-spare=2
> --max-spare=5 --max-conn-per-child=50 --timeout-child=20 --timeout-tcp=20 2>&1
As few as one control file if it's done as I described above, with a single
"switches" file.
Keep in mind, the project objective is to make things easy for a non-admin
type user, not so much an experienced administrator. That's why there is
already a concurrencyincoming control file. I'm simply suggesting that we
move the toaster more in that direction. It is a lot less likely that an
inexperienced admin will screw up the run file this way, and having them
separated will also make it much easier to write a web app for maintaining
them (wouldn't you like to see that?). Besides which, separating parameters
from the code is simply a good programming practice (for many reasons I
won't go into further here).
>>> %{_sysconfdir}/mail/spamassassin/v310.pre
>>> %{_sysconfdir}/mail/spamassassin/v312.pre
>> I'm not so sure about these two.
>
> These too are definitely config files (the .pre extension simply means they
> are loaded before other .cf files). 7 lines are different in mine than those
> distributed (i.e. I've enabled 7 plugins). A normal spamassassin upgrade with
> never overwrite files in /etc/mail/spamassassin, so we shouldn't either.
These should definitely be tagged as noreplace in the spec file. Permanently. ;)
>> The wiki instructions for SURBL say to
>> modify v310.pre to add the loading of URIDNSBL. Couldn't this be included in
>> the stock toaster without changing its behavior (given the -L switch)? I
>> think this would be desirable to have in the stock toaster.
>
> I'm not sure if URIDNSBL is enabled by -L.
"-L" says to use only local rules, which *disables* URIDNSBL, along with
other rules that require internet connectivity to operate. I believe this
flag is intended for stand-alone SA implementations. I don't think it's
generally a good option for the toaster. My guess is that it is intended to
'protect' a toaster that doesn't have caching DNS set up properly.
> But then again, there are so many different permutations I think the best
> option is simply providing stock spamassassin configuration files and assume
> the installing sysadmin will know what he needs (or ask the spamassassin list
> for advice).
One size definitely does not fit all. However, as you, the experienced
administrator, find useful settings, I'd expect that other toaster users
would probably find at least some of these settings useful too. The toaster
project goal is to be preconfigured as much as possible, in a way that will
benefit and be suitable to the most users. I don't think that stock SA
fulfills this goal.
--
-Eric 'shubes'
---------------------------------------------------------------------
QmailToaster hosted by: VR Hosted <http://www.vr.org>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
