🚀 go-pugleaf

Hallo,

Markus Fritsche <jojo@nuddle.invalid> wrote:
> ich bastel gerade im lokalen Netz an einem Newsserver
> und hänge momentan an dem Thema Cleanfeed.
>
> Gibt es zu Clearfeed irgendwo noch eine brauchbare Anleitung,
> da selbst die Infos von Clearfeed teilweise sehr veraltet sind
> und mir persönlich nicht wirklich schlüssig sind.
>
> Ich baue erst eine funktionierende filter_nnrpd.pl, in der
> die Header des Absenders sauber verschlüsselt werden und auch
> Cancel-Lock integriert ist, um diese dann durch die Config von
> Cleanfeed zu ersetzen?
>
> Ich verstehe gerade die Zusammenhänge nicht.
> Kann mir jemand auf die Sprünge helfen?

Da muss ich leider sagen: ich leider nicht. Dass letzten mal, dass ich
einen inn aufgesetzt habe, ist bestimmt schon 20 Jahre her, und das war
IIRC damals noch ohne cleanfeed ... Seit dem habe ich mich etwas inten-
siver mit diablo beschaeftigt und betreue im Prinzip noch so einen, aber
der laeuft im wesentlichen seit Jahren wartungsfrei (wenn ich denn etwas
wesentliches aendern muesste, muesste ich vermutlich auch erst wieder in
der Dokumentation stoebern) ...

Tschuess,
	Juergen Ilse			(juergen@usenet-verwaltung.de)

Markus Fritsche schrieb am 04.11.2020:

> Gibt es zu Clearfeed irgendwo noch eine brauchbare Anleitung,
> da selbst die Infos von Clearfeed teilweise sehr veraltet sind
> und mir persönlich nicht wirklich schlüssig sind.

<https://www.mixmin.net/cleanfeed/>

> Ich baue erst eine funktionierende filter_nnrpd.pl, in der
> die Header des Absenders sauber verschlüsselt werden und auch
> Cancel-Lock integriert ist, um diese dann durch die Config von
> Cleanfeed zu ersetzen?

Nein, natürlich nicht. filter_nnrpd.pl betrifft den nnrpd, wie der Name
schon sagt, also den Teil des INN, der lokale Postings annimmt.
Cleanfeed hingegen betrifft den Feed, mithin filter_innd.pl. Der wird
in der Regel schlicht durch Cleanfeed ersetzt. Was man sonst noch
braucht (bspw. die Implementation der Cancel-Verifikation, kommt dann
in die cleanfeed.local, in Debian dann bspw.
/etc/news/filter/cleanfeed/etc/cleanfeed.local, an die passende Stelle.

Ich schrieb am 04.11.2020:

> Was man sonst noch
> braucht (bspw. die Implementation der Cancel-Verifikation, kommt dann
> in die cleanfeed.local, in Debian dann bspw.
> /etc/news/filter/cleanfeed/etc/cleanfeed.local, an die passende
> Stelle.

Ein 11 Jahre alter Blogbeitrag mit ein paar Links bspw. hier:
<https://netz-rettung-recht.de/archives/1473-INN-Cancel-Lock-und-Cancel-Key.html>

Das eine oder andere muss man möglicherweise mittlerweile anpassen.

Also sprach Markus Fritsche <jojo@nuddle.invalid>

> ich bastel gerade im lokalen Netz an einem Newsserver
> und hänge momentan an dem Thema Cleanfeed.

> Gibt es zu Clearfeed irgendwo noch eine brauchbare Anleitung,
> da selbst die Infos von Clearfeed teilweise sehr veraltet sind
> und mir persönlich nicht wirklich schlüssig sind.

Die letzte Dokumentation von Cleanfeed stammt aus dem Jahr 2008
und ist hier verfügbar:

http://www.mixmin.net/cleanfeed/index.html

> Ich baue erst eine funktionierende filter_nnrpd.pl, in der
> die Header des Absenders sauber verschlüsselt werden und auch
> Cancel-Lock integriert ist, um diese dann durch die Config von
> Cleanfeed zu ersetzen?

Es gibt zwei exit points[1]: Der erste wird aufgerufen, bevor ein Artikel
gepostet wird (aus NNRPD). In diesem hook können Prüfungen durchgeführt,
header manipuliert werden (löschen, hinzufügen, verschlüsseln) und
Artikel abgewiesen werden, die über eine Client-Verbindung gepostet
werden. Der Name des Filters ist per default filter_nnrpd.pl oder
filter_nnrpd.py, je nach Programmiersprache,

Der zweite exit point wird aufgerufen, bevor Artikel, die von Peers
oder dem lokalen NNRPD an INND übergeben werden, von INND akzeptiert
werden. Der Default-Name dieses hooks is filter_innd.pl /
filter_innd.py. Hier wird Cleanfeed eingebunden.

Wenn du Cancel-Lock Keys nicht nur erzeugen, sondern auch prüfen
und die Cancel-Nachrichten ausführen willst, kann das nur in
filter_innd.p[l|y] passieren. In diesem Fall wirst du den
Cleanfeed-Filter, der eingehende Artikel auf Spam-Merkmale
prüft, selbst um die entsprechenden Funktionen erweitern.
Sinnvoller Weise solltest du erst einen funktionierenden Cleanfeed
haben, bevor du dich mit der Verarbeitung von Cancel-Nachrichten
in Abhängigkeit vom Cancel-Key beschäftigen.

[1] Eine Dokumentation der Filter sollte bei deiner INN-Installation
mitgeliefert werden. Sie liegt im doc-Verteichnis und trägt den Namen
hook-perl bzw. hook-python.

--
Time flies like an arrow, fruit flies like a Banana.
http://www.eternal-september.org

Am 05.11.2020 um 06:30 schrieb Ray Banana:
> In diesem Fall wirst du den
> Cleanfeed-Filter, der eingehende Artikel auf Spam-Merkmale
> prüft, selbst um die entsprechenden Funktionen erweitern.
> Sinnvoller Weise solltest du erst einen funktionierenden Cleanfeed
> haben, bevor du dich mit der Verarbeitung von Cancel-Nachrichten
> in Abhängigkeit vom Cancel-Key beschäftigen.

Daher scheint der cleanfeed nun zu laufen.

Gerade wenn man neu in dem Gebiet ist und sich in der Verwaltung eines
Newsserver einarbeiten will, dann sind viele Informationen teilweise
weitläufig verstreut, lückenhaft oder unbrauchbar, da die Seiten, auf
denen die Informationen verlinkt waren, nicht mehr existieren.

Zum Thema Cancel-Lock bin ich auf einen Thread gestoßen, der zwar auch
schon älter ist (2007), aber aus den Information und Code-Schnipseln
lässt sich Cleanfeed evtl. mit ein paar Anpassungen zu Cancel-Lock
Fähigkeiten bewegen.

https://groups.google.com/g/de.comm.software.newsserver/c/FiN6Owl752A/m/MflX7G_VWQQJ

Also sprach Markus Fritsche <jojo@nuddle.invalid>

> Zum Thema Cancel-Lock bin ich auf einen Thread gestoßen, der zwar auch
> schon älter ist (2007), aber aus den Information und Code-Schnipseln
> lässt sich Cleanfeed evtl. mit ein paar Anpassungen zu Cancel-Lock
> Fähigkeiten bewegen.
> https://groups.google.com/g/de.comm.software.newsserver/c/FiN6Owl752A/m/MflX7G_VWQQJ

Yep. Läuft bei mir ;-)


--
Time flies like an arrow, fruit flies like a Banana.
http://www.eternal-september.org

Am 05.11.2020 um 16:39 schrieb Ray Banana:
> Also sprach Markus Fritsche <jojo@nuddle.invalid>
>
>> Zum Thema Cancel-Lock bin ich auf einen Thread gestoßen, der zwar auch
>> schon älter ist (2007), aber aus den Information und Code-Schnipseln
>> lässt sich Cleanfeed evtl. mit ein paar Anpassungen zu Cancel-Lock
>> Fähigkeiten bewegen.
>> https://groups.google.com/g/de.comm.software.newsserver/c/FiN6Owl752A/m/MflX7G_VWQQJ
>
> Yep. Läuft bei mir ;-)
>

Jetzt hat's bei mir 'klick' gemacht,
als ich auf deinen Namen geschaut habe... :-D

Danke für deine Hilfe.

Am 04.11.2020 um 21:50 schrieb Thomas Hochstein:
> Markus Fritsche schrieb am 04.11.2020:
>> Ich baue erst eine funktionierende filter_nnrpd.pl, in der
>> die Header des Absenders sauber verschlüsselt werden und auch
>> Cancel-Lock integriert ist, um diese dann durch die Config von
>> Cleanfeed zu ersetzen?
>
> Nein, natürlich nicht. filter_nnrpd.pl betrifft den nnrpd, wie der Name
> schon sagt, also den Teil des INN, der lokale Postings annimmt.
> Cleanfeed hingegen betrifft den Feed, mithin filter_innd.pl.

Nachdem ich einen frischen Kaffee auf dem Schreibtisch hatte,
war mir dann auch irgendwann aufgefallen, dass es zwei verschiedene
Files sind... ;-D

Am 04.11.2020 um 21:52 schrieb Thomas Hochstein:

> Ein 11 Jahre alter Blogbeitrag mit ein paar Links bspw. hier:
> <https://netz-rettung-recht.de/archives/1473-INN-Cancel-Lock-und-Cancel-Key.html>
>
> Das eine oder andere muss man möglicherweise mittlerweile anpassen.
>

Danke für deine Rückmeldung.

Die einzigen Anpassungen, die mir aufgefallen sind, ist ein
Darstellungsfehler in einzelnen Code-Blöcken, was jedoch dem Alter des
Bolgeintrags geschuldet sein mag. Dort wird der Pfeiloperator teilweise
falsch angezeigt. "->"

Die Seite hat mir jedenfalls sehr gut geholfen.

Markus Fritsche schrieb am 06.11.2020:

> Die einzigen Anpassungen, die mir aufgefallen sind, ist ein
> Darstellungsfehler in einzelnen Code-Blöcken, was jedoch dem Alter
> des Bolgeintrags geschuldet sein mag. Dort wird der Pfeiloperator
> teilweise falsch angezeigt. "->"

Oh, ja - auch in den RegExps. Danke für den Hinweis, ich habe den
Fehler behoben. Das passiert ab und an, wenn man über Jahrzehnte
dasselbe Blog betreibt und sich Code und Plugins ab und an ändern.

> Die Seite hat mir jedenfalls sehr gut geholfen.

Freut mich!

Grüße,
-thh
--
Infos über ...
Newsserver: https://th-h.de/net/usenet/servers/
INN       : https://th-h.de/net/usenet/servers/inn/

Am 04.11.2020 um 14:40 schrieb Markus Fritsche:
> Mahlzeit,
>
> ich bastel gerade im lokalen Netz an einem Newsserver
> und hänge momentan an dem Thema Cleanfeed.
>

Nachdem ich mehrere Posts in einer eigenen Testgruppe,
gepostet. Wollte ich nun testen, ob das Cancel mit Key funktioniert.

Beim INN ist "innflags: -C" in der Config gesetzt.

Jedoch werden keine Cancels ausgeführt, weder Local - noch werden diese
an den zweiten Testserver weitergereicht.

In der Syslog ist folgendes hinterlegt:

-----------
news nnrpd-ssl[5742]: xxxxxxxxxxxxxx.xxxxxxx.de post ok
<xxxxxxxxxxx@news.mydomain.de>
-----------

Der Cancel Lock Eintrag ist im Header des Posts korrekt gesetzt.
Die mit INN::syslog definierten Meldungen werden nicht in der Syslog
vermerkt.

Die cleanfeed.local sieht wie folgt aus:

Auschnitt:

##############################################################################################
###### Cancel-Lock
##############################################################################################
#
     # local_filter_cancel
     #
     sub local_filter_cancel {
        unless($hdr{Control} =~ m/^cancel\s+(<[^>]+>)/i) {
           return "Cancel with broken target ID";
        }
        return verify_cancel(\%hdr, $1, 'Cancel');
     }

     sub local_filter_after_emp {
        if (exists( $hdr{'Supersedes'} )) {
           #return verify_cancel(\%hdr, $hdr{'Supersedes'}, 'Supersedes');
           # verify_cancel is called, but not returned, so the
           # posting is unconditionally accepted
           # verify_cancel calls INN:cancel() if verification suceeds
           verify_cancel(\%hdr, $hdr{'Supersedes'}, 'Supersedes');
        }

        return undef;
     }

sub verify_cancel($$$) {
        my $r_hdr = shift || die;
        my $target = shift;
        my $descr = shift;

        my $headers = INN::head($target) || return "$descr of
non-existing ID $target";

        my %headers;
        for my $line(split(/\s*\n/, $headers))    {
           if ($line =~ m/^([[:alnum:]-]+):\s+(.*)/) {
              $headers{$1} = $2;
           }
        }

        my $lock = $headers{'Cancel-Lock'};
        if (defined($lock)) {
           my $key = $r_hdr->{'Cancel-Key'} || return "$descr of $target
without Cancel-Key";
           #return verify_cancel_key($key, $lock, ' target=' . $target);
           return verify_cancel_key($key, $lock, $target);
        }

        return undef;
     }

     sub verify_cancel_key($$$) {
        my $cancel_key = shift;
        my $cancel_lock = shift;
        my $msg = shift;

        $msg = '' unless(defined($msg));
        # -thh
        my $target = $msg;
        $msg = ' target=' . $msg;

        my %lock;
        for my $l(split(/\s+/, $cancel_lock))   {
           next unless($l =~ m/^(sha1|md5):(\S+)/);
           $lock{$2} = $1;
        }

        for my $k(split(/\s+/, $cancel_key))    {
           unless($k =~ m/^(sha1|md5):(\S+)/) {
             INN::syslog('notice', "Invalid Cancel-Key syntax '$k'.$msg");
             next;
           }

           my $key;
           if ($1 eq 'sha1') {
              $key = Digest::SHA1($2); }
           elsif ($1 eq 'md5') {
              $key = Digest::MD5::md5($2);
           }
           $key = MIME::Base64::encode_base64($key, '');

           if (exists($lock{$key})) {
              INN::syslog('notice', "Valid Cancel-Key $key found.$msg");
              # -thh
              # article is canceled now
              INN::cancel($target) if ($target);
              return undef;
           }
        }

        INN::syslog('notice',
           "No Cancel-Key[$cancel_key] matches
Cancel-Lock[$cancel_lock]$msg"
        );
        return "No Cancel-Key matches Cancel-Lock.$msg";
     }

##############################################################################################
... Script Ende

Ich bin bei dem ganzen nach der Anleitung von Thomas Hochstein
vorgegangen.
(https://netz-rettung-recht.de/archives/1473-INN-Cancel-Lock-und-Cancel-Key.html)

Habe ich irgendwas übersehen?

Gruß,
Markus Fritsche

Markus Fritsche schrieb am 12.11.2020:

> Beim INN ist "innflags: -C" in der Config gesetzt.
>
> Jedoch werden keine Cancels ausgeführt, weder Local - noch werden
> diese an den zweiten Testserver weitergereicht.

Hm. Propagiert werden sollten sie aber in jedem Fall.

> sub verify_cancel($$$) {

Da braucht ...

>        if (defined($lock)) {

... noch einen else-Zweig für Postings, die gar kein Cancel-Lock haben:

   my $lock = $headers{'Cancel-Lock'};
   if (defined($lock)) {
      my $key = $r_hdr->{'Cancel-Key'} ||
                     return "$descr of $target without Cancel-Key";
      #return verify_cancel_key($key, $lock, ' target=' . $target);
      return verify_cancel_key($key, $lock, $target);
   } else {
    # -thh
    # no cancel-lock: go ahead and cancel anyway!
    INN::cancel($target);
   }

Außerdem braucht man unter einem nur halbwegs aktuellem Debian statt
des Moduls "Digest::SHA1" das Modul "Digest::SHA::sha1"; alle Aufrufe
im Code sind entsprechend anzupassen.

> Habe ich irgendwas übersehen?

Steht irgendwas im (Error-)Log des Newsservers?

Läuft das Script per se fehlerfrei?
(perl cleanfeed.local oder perl -w cleanfeed.local)

Sind die notwendigen Module eingebunden?
| use MIME::Base64();
| use Digest::SHA();
am Anfang von cleanfeed.local

Sind die Module installiert?

(Ist etwas länger her, dass ich mich näher damit befasst habe; wenn es
mal läuft, dann läuft es halt ...)

Grüße,
-thh

Am 12.11.2020 um 20:26 schrieb Thomas Hochstein:
> Markus Fritsche schrieb am 12.11.2020:
>
> Hm. Propagiert werden sollten sie aber in jedem Fall.

Ich habe die Kiste mal komplett neu gestartet, und abgesendete Cancels
werden nun auch in der news log vermerkt.

Nov 12 16:27:30.067 + localhost <rojANDeh6$2mn$5@news.mydomain.de>
(@0500000000020000000000B6630700000000@) 899 inpaths! ..........

Auf dem zweiten Testserver kommt der Cancel nun auch an:

Nov 12 16:27:30.073 + news.mydomain.de
<rojANDeh6$2mn$5@news.mydomain.de>
(@0500000000020000000000B6630600000000@) 916 inpaths! ..........

Gleiches gilt für Superseeds.

>     my $lock = $headers{'Cancel-Lock'};
>     if (defined($lock)) {
>        my $key = $r_hdr->{'Cancel-Key'} ||
>                       return "$descr of $target without Cancel-Key";
>        #return verify_cancel_key($key, $lock, ' target=' . $target);
>        return verify_cancel_key($key, $lock, $target);
>     } else {
>      # -thh
>      # no cancel-lock: go ahead and cancel anyway!
>      INN::cancel($target);
>     }

Habe ich geändert bzw. erweitert.

> Außerdem braucht man unter einem nur halbwegs aktuellem Debian statt
> des Moduls "Digest::SHA1" das Modul "Digest::SHA::sha1"; alle Aufrufe
> im Code sind entsprechend anzupassen.

Korregiert.

> Steht irgendwas im (Error-)Log des Newsservers?

errorlog und news.err sind beide leer.

> Läuft das Script per se fehlerfrei?
> (perl cleanfeed.local oder perl -w cleanfeed.local)

@news:/etc/news/filter/cleanfeed# perl -w cleanfeed.local
Name "main::lines" used only once: possible typo at cleanfeed.local line
308.
Name "main::localfeed" used only once: possible typo at cleanfeed.local
line 49.
Name "main::Moderated" used only once: possible typo at cleanfeed.local
line 308.
Name "main::localpost" used only once: possible typo at cleanfeed.local
line 105.

Zeile 49:
if ($localfeed) {

Zeile: 105:
if ($config{watch_cancels} and $localpost) {

Zeile: 308:
print
$now.$config_dir.$lines.%Restricted_Groups.%Moderated.%config_local.%config_append.@followups
if 0; # lint food

> Sind die notwendigen Module eingebunden?

Ganz oben eingebunden:

use MIME::Base64();
use Digest::SHA();
use Digest::MD5();

> Sind die Module installiert?

Sind installiert und aktuell:

Digest::SHA is up to date (6.02).
MIME::Base64 is up to date (3.16).
Digest::MD5 is up to date (2.58).

> (Ist etwas länger her, dass ich mich näher damit befasst habe; wenn es
> mal läuft, dann läuft es halt ...)

Ich bin dir trotzdem für deine Hilfe dankbar.

--
Gruß,
Markus Fritsche

Markus Fritsche wrote:
>
> Ich baue erst eine funktionierende filter_nnrpd.pl, in der
> die Header des Absenders sauber verschlüsselt werden und auch
> Cancel-Lock integriert ist, um diese dann durch die Config von
> Cleanfeed zu ersetzen?
>
Ich sehe diesen Thread erst jetzt, aber dir wurde ja schon von
Leuten geholfen, die mehr davon verstehen als ich. Nur eine Anmerkung
dazu: Zum Thema Cancel-Lock gibt es den RFC8315 und der Autor desselben
würde sich bestimmt freuen, wenn neu aufgesetzte Server diesem RFC
entsprechen würden. U.a. ist da SHA1 als obsolete eingestuft und sollte
nur aus Kompatibilitätsgründen implementiert werden, das passt also.
Aktuell sind da allerdings SHA256 und SHA512, die solltest du bei dieser
Gelegenheit IMHO auch aufnehmen.

Das i-Tüpfelchen wäre natürlich eine Syntax-Prüfung von Cancel-Lock und
Cancel-Key nach RFC8315 ;-)
--
Emil
XMPP/Jabber-ID: emil@wieslauf.sub.de
Fingerprint:    56B37A9E 5509BBEF 45CCA41B 0E5F42A2
                AC8EFAE8 55B2CE3E 5BB84B63 5FFA636A

Am 13.11.2020 um 01:28 schrieb Emil Schuster:
> Ich sehe diesen Thread erst jetzt, aber dir wurde ja schon von
> Leuten geholfen, die mehr davon verstehen als ich. Nur eine Anmerkung
> dazu: Zum Thema Cancel-Lock gibt es den RFC8315 und der Autor desselben
> würde sich bestimmt freuen, wenn neu aufgesetzte Server diesem RFC
> entsprechen würden. U.a. ist da SHA1 als obsolete eingestuft und sollte
> nur aus Kompatibilitätsgründen implementiert werden, das passt also.
> Aktuell sind da allerdings SHA256 und SHA512, die solltest du bei dieser
> Gelegenheit IMHO auch aufnehmen.

Laut der RFC8315 ist SHA1 zwar als "obsolete" eingestuft, jedoch halte
ich dies für zwingend erforderlich, da SHA256 und SHA512 bisher von noch
keinem System umgesetzt wurde (kann mich auch irren).

SHA256 und SHA512 werden bei mir umgesetzt, sobald der Rest des
Cancel-Locks läuft. Vorher wird die Kiste nicht online gehen. Dies wird
auch noch eine ganze Weile dauern, da Perl nicht unbedingt zu meine
Top-Sprachen gehört und vieles nach dem Try-and-Error Prinzip abläuft.
- Deshalb läuft die Kiste auch aktuell nur im lokalen Netz.

--
Gruß,
Markus Fritsche

Markus Fritsche wrote:
>
> Laut der RFC8315 ist SHA1 zwar als "obsolete" eingestuft, jedoch halte
> ich dies für zwingend erforderlich, da SHA256 und SHA512 bisher von
> noch keinem System umgesetzt wurde (kann mich auch irren).
>
Ich auch, da habe ich mich wohl missverständlich ausgedrückt.

> SHA256 und SHA512 werden bei mir umgesetzt, sobald der Rest des
> Cancel-Locks läuft.

Das freut mich. Da sind wir schon zu zweit :-)
--
Emil
XMPP/Jabber-ID: emil@wieslauf.sub.de
Fingerprint:    56B37A9E 5509BBEF 45CCA41B 0E5F42A2
                AC8EFAE8 55B2CE3E 5BB84B63 5FFA636A

Markus Fritsche wrote:
> Am 13.11.2020 um 01:28 schrieb Emil Schuster:
> >
> > Ich sehe diesen Thread erst jetzt, aber dir wurde ja schon von
> > Leuten geholfen, die mehr davon verstehen als ich. Nur eine Anmerkung
> > dazu: Zum Thema Cancel-Lock gibt es den RFC8315 und der Autor desselben
> > würde sich bestimmt freuen, wenn neu aufgesetzte Server diesem RFC
> > entsprechen würden. U.a. ist da SHA1 als obsolete eingestuft und sollte
> > nur aus Kompatibilitätsgründen implementiert werden, das passt also.
> > Aktuell sind da allerdings SHA256 und SHA512, die solltest du bei dieser
> > Gelegenheit IMHO auch aufnehmen.
>
> Laut der RFC8315 ist SHA1 zwar als "obsolete" eingestuft, jedoch halte
> ich dies für zwingend erforderlich, da SHA256 und SHA512 bisher von
> noch keinem System umgesetzt wurde (kann mich auch irren).

Die Unterstützung für SHA1 zeitnah fallen zu lassen wird auch
ausdrücklich nicht empfohlen (siehe Kapitel 6 [1], Absatz 2).

Keys mit unterschiedlichen Algorithmen prüfen zu können schränkt
die Kompatibilität nicht ein.

Beim erzeugen ist es erlaubt mehrere Locks bzw. Keys hinzuzufügen,
z.B. mit SHA1 und SHA256.


__________
[1] <https://tools.ietf.org/html/rfc8315#section-6>

Am 13.11.2020 um 13:23 schrieb Emil Schuster:
> Ich auch, da habe ich mich wohl missverständlich ausgedrückt.

Oder ich habe es falsch interpretiert. ;-)

>> SHA256 und SHA512 werden bei mir umgesetzt, sobald der Rest des
>> Cancel-Locks läuft.

> Das freut mich. Da sind wir schon zu zweit :-)

Ich denke, das wird dann auch eine ganze Zeit so bleiben...

Einige Server nutzen teilweise gar kein Cancel Lock und wenn,
dann nur SHA1. Zudem laufen viele Newsserver einfach nur noch,
Aktualisierungen oder Anpassungen werden dort kaum noch durchgeführt.

Bei Hardwareschäden oder vergleichbares, werden die Server dann meist
ersatzlos vom Netz genommen, da sich keiner mehr die Mühe machen will,
einen neuen aufzusetzen bzw. meist auch keine Zeit bzw. Hardware von der
Verwaltung dafür freigegeben wird.

--
Gruß,
Markus Fritsche

Am 12.11.2020 um 20:26 schrieb Thomas Hochstein:
>
> Hm. Propagiert werden sollten sie aber in jedem Fall.
>

Ich habe mir das Ganze nun einige Male durch den Kopf gehen lassen
und habe versucht die Verabeitung der Cancels beim INN nachzuvollziehen.

Wenn der INN ohne C-Flag gestartet ist, werden eingehende Cancels direkt
von INN ausgeführt, sofern der Path des Posts und des Cancels gleich
sind. (ohne vorhandene Cancel-Lock prüfung in den Filtern)

Wenn dann aber die Filter für Cancels in der Cleanfeed.local eingetragen
sind, müsste er doch die Cancels auch nur ausführen, wenn diese durch
den Filter bzw. die Prüfung kommen.  Durch die innrd.pl muss ja alles
durch, also auch die Cancels. Egal ob von extern oder von einem Nutzer
über nnrpd. - In diesem Fall wäre dann der C-Flag der Schlüssel, warum
Cancels nicht auf dem Server ausgefühgrt, aber weitergesendet werden.

Wenn jetzt der INN aber mit dem C-Flag gestartet wird, werden ja die
interne Routinen zum Canceln von Artikeln nicht mehr ausgeführt und der
Server führt keine Cancels aus und gibt diese lediglich nur noch über
die Feeds weiter und er Befehl "INN::cancel($target);" in der
cleanfeed.local soll die Cancel Routinen des INN dennoch starten bei
bedarf starten.

Nur scheinbar hängt es bei mir an dem Befehl "INN::cancel($target);",
dass Cancels nicht mit aktiven C-Flag lokal ausgeführt werden.

Ist mein Gedankengang korrekt oder liege ich komplett daneben?

Blockiert er Cancels totzdem, wenn der INN ohne C-Flag gestartet ist und
ein Cancel mit falschem Key eingeht?

Falls ja, dann würde es ja einfach reichen in der inn.conf, den
Parameter "innflags: -C" auszukemmentieren und in der cleanfeed.loacal
die beiden return verify_cancel... und verify_cancel... zu tauschen,
sowie das INN::cancel($target); auszukommentieren.

--
Gruß,
Markus Fritsche