Send inn-workers mailing list submissions to
[email protected]
To subscribe or unsubscribe via the World Wide Web, visit
https://lists.isc.org/mailman/listinfo/inn-workers
or, via email, send a message with subject or body 'help' to
[email protected]
You can reach the person managing the list at
[email protected]
When replying, please edit your Subject line so it is more specific
than "Re: Contents of inn-workers digest..."
Today's Topics:
1. Re: Facilitating installation and update of anti-spam filter
(Julien ?LIE)
2. Re: Facilitating installation and update of anti-spam filter
(Julien ?LIE)
3. Re: About external or technical configuration files
(Andreas Kempe)
4. Re: Facilitating installation and update of anti-spam filter
(Grant Taylor)
----------------------------------------------------------------------
Message: 1
Date: Mon, 11 Jul 2022 19:28:37 +0200
From: Julien ?LIE <[email protected]>
To: [email protected]
Subject: Re: Facilitating installation and update of anti-spam filter
Message-ID: <[email protected]>
Content-Type: text/plain; charset=UTF-8; format=flowed
Hi Grant,
>> Unfortunately I am not aware of such a mailing-list...
>
> That sounds like something that could be rectified.
Instead of a new mailing-list, why not use existing newsgroups like
news.admin.misc, news.software.misc or news.admin.announce? (the latter
is moderated)
(Rare) changes to control.ctl, NoCeM issuers, moderators & like could be
announced there...
Same thing in case there's a new release of Cleanfeed, PyClean or any
other news-related software.
Could be worth trying anyway. I may ask Tim Skirvin what he would think
of using news.admin.announce for such information.
>> Which in fact raises the question of how to ease the administration of
>> a news server and inform admins of changes they should have a look at?
>
> I don't know.? If INN supports include file directive(s) and (re)setting
> values multiple times, I could see how the configuration files could be
> addressed.? E.g. have default in <file>, which has something like
> "include <file>.local" as it's last line.? Then any INN / distro
> provided settings that the admin wants to overwrite could be placed in
> the <file>.local file.
I see what you mean. Unfortunately, INN does not support that feature
for all configuration files; nocem.ctl and moderators do not have that;
control.ctl.local can somehow do the job (but essentially to add new
rules, the idea isn't to put a drop of everything at the beginning of
control.ctl.local and then re-add stuff...).
> There might be an opportunity for some minor refactoring to make
> supporting updates easier.
Probably, though we could try to start a better communication about such
changes in one or several newsgroups.
--
Julien ?LIE
??Ce vieux forban d'Asthmatix, il ne manquait pas d'air?!?? (Ast?rix)
------------------------------
Message: 2
Date: Mon, 11 Jul 2022 19:38:40 +0200
From: Julien ?LIE <[email protected]>
To: [email protected]
Subject: Re: Facilitating installation and update of anti-spam filter
Message-ID: <[email protected]>
Content-Type: text/plain; charset=UTF-8; format=flowed
Hi Jesse,
> I can?t get pyClean to work with Python 3.8/3.9 and had to revert to using
> Python 2.7.
That sounds a bug to fix, and PyClean (as well as Cleanfeed) seems to no
longer be maintained :-/
> I stumbled upon a fork whose maintainer took the time to provide a
> basic install guide that it was clear what to do.
Indeed:
https://github.com/doug-letough/PyClean
> I?d like the filter to run as an external process. During busy times
> innd with pyClean is using ~40-60% more CPU than another innd process
> handing the same feed with no filtering.
I've not checked on my news server. It seems pretty CPU-consuming!
> Whatever is decided, let?s please not introduce another ?Cleanfeed? into the
> world
I have not planned to write another Cleanfeed. There are already tons
of other things to do!
--
Julien ?LIE
??Ce vieux forban d'Asthmatix, il ne manquait pas d'air?!?? (Ast?rix)
------------------------------
Message: 3
Date: Mon, 11 Jul 2022 20:42:31 +0200
From: Andreas Kempe <[email protected]>
To: Julien ?LIE <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: About external or technical configuration files
Message-ID: <[email protected]>
Content-Type: text/plain; charset=iso-8859-1
On Sat, Apr 16, 2022 at 12:41:10PM +0200, Julien ?LIE wrote:
> Hi all,
>
Hello Julien,
I was meaning to answer this mail, but it slipped my mind so here's a
rather late response.
> Do you think something should be done for the following configuration
> files in <pathetc>, that are not automatically updated with a new INN
> version?
> - control.ctl
> - innwatch.ctl
> - moderators
> - nocem.ctl
>
> Currently, a news admin needs taking care manually of possible changes.
>
> I doubt people really modify innwatch.ctl... It may be a file to move
> into <pathlib> so that bug fixes are automatically taken into account
> during an update.
> We could have the following behaviour: use <pathetc>/innwatch.ctl.local
> if present. Otherwise, use <pathlib>/innwatch.ctl.
> Any opinion about that?
>
I think that any file that needs a new version from the INN project
for the software to work as intended should be moved away from the etc
directory and be unconditionally updated when the software is updated.
In your innwatch.ctl case, I think your suggestion sounds reasonable.
>
> Changes to control.ctl and nocem.ctl are not always straight-forward, as
> a manual intervention in PGP keys could be needed. So I would be
> inclined not to change anything, unless someone has an interesting idea.
>
> Besides, changes to these "external" files can happen at any time, and
> are not linked to an INN release. Same thing for the moderators file.
>
> Maybe a simple tool that the admin could manually start, or put in cron,
> that just download the reference file (from ftp.isc.org or the GitHub
> INN repository for instance) and output the diff between the local
> installed file could be useful and be an improvement?
>
My take is that INN should strive to own and separate out anything
that might need updates from the upstream without worrying about local
changes.
To make an example, we can look at nocem.ctl. If INN wants to provide
a base nocem.ctl file that recognises some keys, I think that both
nocem.ctl and the keys needed should be provided and installed by the
installation process in the library directory. There would then be a
configuration directive to either disable or enable the bundled keys.
If the keys change upstream, INN would make a new release with updated
bundled keys and configuration.
The nocem.ctl provided under etc would only contain formatting
instructions, but otherwise be empty and would not be touched by
updates to INN. Both files would then be read and used, unless the
bundled nocem.ctl is explicitly disabled in the configuration.
If INN does not want to take responsibility and do releases of INN to
update the bundled nocem.ctl and keys, I don't think it should bundle
them at all. Instead, I think either a separate package should be
provided for them or, as you suggested, a little script that
automatically fetches these files could be provided.
They way CA certificates are handled on most systems is a good
example. Firefox needs these to function, but on FreeBSD they are
shipped as the ca_root_nss package that is installed independently of
the browser itself. If one wants to use local CA certificates, one
simply adds them as separate files in the CA root directory and these
local files are untouched by any updates.
> Incidentally, this tool may also download/compare the installed version
> of other common packages like Cleanfeed, PyClean or like.
>
On FreeBSD, cleanfeed is provided as its own package that installs it
with a rudimentary configuration in the correct place in the INN
directory hierarchy. I think package and software management is best
left to the system's own distribution method.
In short, I think INN should work towards drawing a clear line between
configuration that is managed by the administrator and configuration
that is managed by the upstream. It should then be free to update the
upstream configuration without regard for local changes.
Cordially,
Andreas Kempe
------------------------------
Message: 4
Date: Mon, 11 Jul 2022 14:16:30 -0600
From: Grant Taylor <[email protected]>
To: [email protected]
Subject: Re: Facilitating installation and update of anti-spam filter
Message-ID:
<[email protected]>
Content-Type: text/plain; charset="utf-8"; Format="flowed"
On 7/11/22 11:28 AM, Julien ?LIE wrote:
> Hi Grant,
Hi Julien,
> Instead of a new mailing-list, why not use existing newsgroups like
> news.admin.misc, news.software.misc or news.admin.announce? (the latter
> is moderated)
Sure.
I think it's probably okay to depend on Usenet in the context of a piece
of Usenet server software.
Depending on Usenet outside of Usenet is a little bit of a stretch IMHO.
There is also something to be said for non-Usenet based communications
in support of Usenet. E.g. when the Usenet software isn't working and
you need help to get it working. -- Though that's out of context. /me
shuts his mouth.
> I see what you mean.? Unfortunately, INN does not support that feature
> for all configuration files; nocem.ctl and moderators do not have that;
> control.ctl.local can somehow do the job
The other thing that I've been known to do in some cases like this is to
fall back to m4 (et al.) to combine files for me to produce the new output.
Or maybe sed.
Maybe automating some of this with a script / make file. (See how older
FreeBSD used make files to manipulate some things for Sendmail.)
> (but essentially to add new rules, the idea isn't to put a drop of
> everything at the beginning of control.ctl.local and then re-add
> stuff...).
I wasn't thinking dropping everything. More of a most recent setting
wins type thing. E.g.
example_file:
USER_ONE=Bob
USER_TWO=Ed
source example_file.local
example_file.local:
USER_ONE=Tom
Hence the example_file.local overwriting the USER_ONE value to be Tom
while retaining the USER_TWO value of Ed.
> Probably, though we could try to start a better communication about such
> changes in one or several newsgroups.
+1
--
Grant. . . .
unix || die
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4017 bytes
Desc: S/MIME Cryptographic Signature
URL:
<https://lists.isc.org/pipermail/inn-workers/attachments/20220711/be05ea8b/attachment.bin>
------------------------------
Subject: Digest Footer
_______________________________________________
inn-workers mailing list
[email protected]
https://lists.isc.org/mailman/listinfo/inn-workers
------------------------------
End of inn-workers Digest, Vol 142, Issue 6
*******************************************
