[INN2] Statistiken und CNFS

[Christian Garbs]

Mahlzeit!

Durch die letzten Fragen zu CNFS und den Hinweis, dass ggf. viel
Traffic in den test-Gruppen zum schnelleren Durchlaufen des Buffers
führt, habe ich mal auf meinen Server geguckt. Der läuft, wie sich
das gehört, seit Jahren problemlos vor sich hin, dementsprechend
schlecht aufgestellt bin ich bei Admin- und Wartungstätigkeiten.

Meine RRD-Statistiken (Schreibposition in den CNFS-Buffern vs. Zeit)
zeigt ganz klar, dass in den letzten Monaten der Buffer INTL schneller
durchrotiert als sonst. Auch DE ist leicht gestiegen:

Loading Image...

Da könnte man mal optimieren.

Ich habe drei Buffer:

DE für de.*, REGIO für lokales (also z.B. kiel.* und muenster.*) und
INTL für den ganzen Rest. Wenn jetzt tatsächlich hoher Traffic auf
test.* oder alt.test.* kommt, landet das in INTL.

Im das mal strukturiert zu analysieren und irgendwas zu ändern, habe
ich zwei Fragen:

1. Wie kriege ich am besten raus, in welchen Newsgruppen am meisten
Traffic ist, also wer mir INTL so oft rotieren lässt? Gibt's da
ein schönes Statistiktool?
Ich kriege zwar täglich eine Status-Mail, die ist aber über die
Server-Connections.

2. Kann man im laufenden Betrieb die CNFS-Zuordnungen ändern oder
kommt etwas durcheinander?
Wenn ich z.B. zusätzlich einen TEST-Buffer anlege, werden da ja nur
zukünftige Artikel abgelegt. Weiß inn, dass die alten Einträge
aus den Test-Gruppen noch in INTL liegen?
Werden die Gruppen-Zuordnungen für CNFS nur beim Speichern von
Artikeln benutzt oder auch generell zum Lookup für bestehende
Artikel?

Wenn ich erstmal in die richtige Richtung loslaufe, kann ich mich
vermutlich weiter durchwursteln. Aber das ist alles so lange her mit
der Newskonfiguration, dass ich wieder ziemlich bei 0 anfange.

Danke und Gruß
Christian

[Ray Banana]

Post by Christian Garbs
1. Wie kriege ich am besten raus, in welchen Newsgruppen am meisten
Traffic ist, also wer mir INTL so oft rotieren lässt? Gibt's da
ein schönes Statistiktool?
Ich kriege zwar täglich eine Status-Mail, die ist aber über die
Server-Connections.

Statistik-Tool müsste man sich bauen, Daten sammeln über einen File feed
in newsfeeds, den man mit dem Parameter W mit den benötigten Datenelementen
bestückt, in regelmäßigen Abständen flusht und ausliest.

Was INTL zur Zeit zum rotieren bringt, ist höchstwahrscheinlich die seit
September laufende Spam-Welle von Google Groups. Ich habe im November
~1,4 Millionen Spams von GoogleGroups abgefangen, in 2317 Gruppen, überwiegend
Big 8.

Post by Christian Garbs
2. Kann man im laufenden Betrieb die CNFS-Zuordnungen ändern oder
kommt etwas durcheinander?
Wenn ich z.B. zusätzlich einen TEST-Buffer anlege, werden da ja nur
zukünftige Artikel abgelegt. Weiß inn, dass die alten Einträge
aus den Test-Gruppen noch in INTL liegen?

Der Speicherort steht in der History, solange die CNFS noch in der
cycbuff.conf vorhanden sind, werden sie auch gefunden.

Post by Christian Garbs
Werden die Gruppen-Zuordnungen für CNFS nur beim Speichern von
Artikeln benutzt oder auch generell zum Lookup für bestehende
Artikel?

Nur zum Speichern. BTDT.

[Christian Garbs]

Mahlzeit!

Post by Ray Banana

Post by Christian Garbs
1. Wie kriege ich am besten raus, in welchen Newsgruppen am meisten
Traffic ist, also wer mir INTL so oft rotieren lässt? Gibt's da
ein schönes Statistiktool?
Ich kriege zwar täglich eine Status-Mail, die ist aber über die
Server-Connections.

Statistik-Tool müsste man sich bauen, Daten sammeln über einen File feed
in newsfeeds, den man mit dem Parameter W mit den benötigten Datenelementen
bestückt, in regelmäßigen Abständen flusht und ausliest.

Ah - da kann ich bestimmt vom top1000-Skript abgucken, das dürfte
ungefähr das gleiche machen, nur halt mit Path: statt Newsgroups:

Ich werde basteln :)

Post by Ray Banana
Was INTL zur Zeit zum rotieren bringt, ist höchstwahrscheinlich die
seit September laufende Spam-Welle von Google Groups. Ich habe im
November ~1,4 Millionen Spams von GoogleGroups abgefangen, in 2317
Gruppen, überwiegend Big 8.

Grr, da kann ich dann wohl wenig gegen tun - der Server soll ja
peeren, da kann ich schlecht ganz GoogleGroups ablehnen.

Vielleicht mache ich einfach INTL etwas größer oder lasse es so - da
ich keine echten Nutzer auf dem Server habe, müssen die Artikel nur so
lange vorhalten, bis die Artikel an alle Peers verteilt sind.

Der einzige Downstream-Nutzer bin ich selbst - ich könnte das dann
hier lokal filtern, aber in den Gruppen, die ich lese, ist es zum
Glück noch ruhig.

Post by Ray Banana

Post by Christian Garbs
2. Kann man im laufenden Betrieb die CNFS-Zuordnungen ändern oder
kommt etwas durcheinander?
Wenn ich z.B. zusätzlich einen TEST-Buffer anlege, werden da ja nur
zukünftige Artikel abgelegt. Weiß inn, dass die alten Einträge
aus den Test-Gruppen noch in INTL liegen?

Der Speicherort steht in der History, solange die CNFS noch in der
cycbuff.conf vorhanden sind, werden sie auch gefunden.

Post by Christian Garbs
Werden die Gruppen-Zuordnungen für CNFS nur beim Speichern von
Artikeln benutzt oder auch generell zum Lookup für bestehende
Artikel?

Nur zum Speichern. BTDT.

Bestens, dann kann ich da ganz locker umbauen.

Danke!
Christian

[Urs Janßen]

Post by Christian Garbs

Post by Ray Banana
Was INTL zur Zeit zum rotieren bringt, ist höchstwahrscheinlich die
seit September laufende Spam-Welle von Google Groups. Ich habe im
November ~1,4 Millionen Spams von GoogleGroups abgefangen, in 2317
Gruppen, überwiegend Big 8.

Grr, da kann ich dann wohl wenig gegen tun - der Server soll ja
peeren, da kann ich schlecht ganz GoogleGroups ablehnen.

warum nicht? wer den google traffic wirklich haben will bekommt ihn sicher
noch von wo anders und der rest der peers ist froh ueber jeden server der
das nicht durchlaesst.

du kannst auch versuchen die passenden nocems "einzusammeln" und dann in der
"gpg ist doof weil es das format geandert hat sich ein dreck um aeltere keys
kuemmert"-hoelle aufwachen.

[Ray Banana]

Post by Urs Janßen
du kannst auch versuchen die passenden nocems "einzusammeln" und dann in der
"gpg ist doof weil es das format geandert hat sich ein dreck um aeltere keys
kuemmert"-hoelle aufwachen.

Es gibt exakt einen PGP-Key, der für Steuernachrichten verwendet wird
und gpg1 benötigt und das lässt sich mit Fassung tragen. Hölle ist
anders.

[Urs Janßen]

Post by Ray Banana
Es gibt exakt einen PGP-Key, der für Steuernachrichten verwendet wird
und gpg1 benötigt und das lässt sich mit Fassung tragen. Hölle ist
anders.

urs% lynx -dump https://ftp.isc.org/pub/pgpcontrol/PGPKEYS | grep -c 2.6.3i
55

[Christian Garbs]

Mahlzeit!

Post by Urs Janßen

Post by Christian Garbs

Post by Ray Banana
Was INTL zur Zeit zum rotieren bringt, ist höchstwahrscheinlich die
seit September laufende Spam-Welle von Google Groups. Ich habe im
November ~1,4 Millionen Spams von GoogleGroups abgefangen, in 2317
Gruppen, überwiegend Big 8.

Grr, da kann ich dann wohl wenig gegen tun - der Server soll ja
peeren, da kann ich schlecht ganz GoogleGroups ablehnen.

warum nicht? wer den google traffic wirklich haben will bekommt ihn sicher
noch von wo anders und der rest der peers ist froh ueber jeden server der
das nicht durchlaesst.

Hmm, das wäre vielleicht eine Option.

Post by Urs Janßen
du kannst auch versuchen die passenden nocems "einzusammeln" und dann in der
"gpg ist doof weil es das format geandert hat sich ein dreck um aeltere keys
kuemmert"-hoelle aufwachen.

Das hilft mir dann aber nichts mehr beim ursprünglichen Problem "der
Buffer rotiert so schnell", weil der Spam erst empfangen und später
gecancelt wird, oder?

Gruß
Christian

[Urs Janßen]

Post by Christian Garbs
Das hilft mir dann aber nichts mehr beim ursprünglichen Problem "der
Buffer rotiert so schnell", weil der Spam erst empfangen und später
gecancelt wird, oder?

richtig

[Christian Garbs]

Mahlzeit!

Post by Urs Janßen

Post by Christian Garbs

Post by Ray Banana
Was INTL zur Zeit zum rotieren bringt, ist höchstwahrscheinlich die
seit September laufende Spam-Welle von Google Groups. Ich habe im
November ~1,4 Millionen Spams von GoogleGroups abgefangen, in 2317
Gruppen, überwiegend Big 8.

Grr, da kann ich dann wohl wenig gegen tun - der Server soll ja
peeren, da kann ich schlecht ganz GoogleGroups ablehnen.

warum nicht? wer den google traffic wirklich haben will bekommt ihn
sicher noch von wo anders und der rest der peers ist froh ueber
jeden server der das nicht durchlaesst.

Ich glaube, ich fahre da jetzt auch den harten Kurs:

Ich habe inzwischen meinen ersten Filter geschrieben und in
/etc/news/filter/filter_innd.pl (Debian) unter filter_messageid()
folgendes eingetragen:

$rval = 'No' if ($messageid =~ /\@googlegroups\.com>?/i);

Also alles ignorieren, was eine Message-ID von googlegroups.com hat.

Das machte sich unerwartet deutlich in meinen Server-Statistiken
bemerkbar (das ist nur ein armer, kleiner, schwachbrüstiger aber
billiger Root-Server):

- die CNFS-Buffer-Statistik hat einen deutlichen Knick bekommen, die
Füllrate hat sich stark verlangsamt

- eingehender und ausgehender Traffic der Servers sind um mehr als
80% eingebrochen (der Server war wohl hauptsächlich eine
Usenet-Spamschleuder!)

- ich hab 1 GB Swap weniger in Benutzung

- CPU-Last leicht runter (von 98% auf 99% idle, die Kiste ist eher
Memory- und IO-bound)


Auch, wenn ich den einen oder anderen echten Artikel von GoogleGroups
wegfiltern sollte: Das bleibt wohl so!

Gruß
Christian

[Christian Garbs]

Mahlzeit!

Post by Ray Banana

Post by Christian Garbs
1. Wie kriege ich am besten raus, in welchen Newsgruppen am meisten
Traffic ist, also wer mir INTL so oft rotieren lässt? Gibt's da
ein schönes Statistiktool?
Ich kriege zwar täglich eine Status-Mail, die ist aber über die
Server-Connections.

Statistik-Tool müsste man sich bauen, Daten sammeln über einen File feed
in newsfeeds, den man mit dem Parameter W mit den benötigten Datenelementen
bestückt, in regelmäßigen Abständen flusht und ausliest.

Ich habe seit letzter Woche etwas zusammengeschraubt, das funktioniert
für meine Zwecke, vielleicht kann es ja jemand gebrauchen:


- - - - 8< - - - -


#!/bin/bash
#
# Testimplementierung für das Ermitteln von Newsgroup-Statistiken (wieviele Artikel in welche Gruppen)
#
# see /etc/news/newsfeeds

DB=/var/lib/news/groupstats.db
LOG=/var/log/news/groupstats.log

sql() {
sqlite3 -batch "$DB"
}

init_db_maybe() {
sql <<EOF
CREATE TABLE IF NOT EXISTS posting (
date INTEGER,
site TEXT,
"group" TEXT,
googlespam INTEGER
);
EOF
}

store() {
local site=$1 groups=$2 path=$3

if [[ $path =~ google-groups.googlegroups.com!not-for-mail ]]; then
spam=1
else
spam=0
fi

local IFS=,
for group in $groups; do
printf 'INSERT INTO posting ( date, site, "group", googlespam ) VALUES ( datetime(), "%s", "%s", %d );' "$site" "$group", "$spam"
done | sql
}

init_db_maybe

{
echo "$0 here FRESH START"
while read -r line; do
echo "$line"
store $line
done
} | ts > "$LOG"


- - - - >8 - - - -

1. Das benötigt sqlite3(1) und ts(1)
2. Da GROUP ein reserviertes SQL-Keyword ist, muss man die Spalte in
einem SELECT als "group" angeben.


Der newsfeeds-Eintrag dazu:

groupstats!\
:*,\
:Tc,WsNP:/usr/local/sbin/groupstats


Das ist das erste (aber bestimmt nicht letzte) Mal, dass ich sqlite
nutze. Sehr praktisch, weil man sich nach dem Sammeln die Abfragen
ausdenken kann, man kann ja flexibel SELECTen.

Und das lässt sich bestimmt noch optimieren, indem man nicht für jeden
Artikel das sqlite-Binary aufruft, sondern dauerhaft dort
hineinpiped. Ich hatte aber noch keine Lust, mich mit COMMIT und
"wieviele der Daten bleiben erhalten, wenn die Pipe plötzlich stirbt"
zu beschäftigen.

Post by Ray Banana
Was INTL zur Zeit zum rotieren bringt, ist höchstwahrscheinlich die
seit September laufende Spam-Welle von Google Groups. Ich habe im
November ~1,4 Millionen Spams von GoogleGroups abgefangen, in 2317
Gruppen, überwiegend Big 8.

Das kann ich bestätigen. Nach ein paar Stunden Statistikerfassung war
die aktivste Gruppe bei mir microsoft.public.project, die hatte mehr
Traffic als die Plätze 2-5 zusammen. Nach kurzem Quergucken ist die
Gruppe zu 100% voll mit GoogleGroups-Spam.

Was haben wir es toll in den von mir gelesenen de.-Gruppen.


Weitere Ergebnisse meiner Statistik:

- Das Verhältnis Spam (im Sinne von: "kommt von GoogleGroups") zu
allen anderen Artikeln ist mehr als 7:1. Uff. Das ist übler als
gedacht.


- Ich weiß jetzt, welcher Peer mir manchmal Artikel nach local.misc
spült.

Dazu eine Folgefrage: Wenn ich in der incoming.conf bei diesem Peer

patterns: *,!local.*

setze, um diese Artikel loszuwerden - wie verhält sich das bei
Crossposts? Ich hätte gerne, dass der Artikel in den anderen Gruppen
erscheint, in local.* aber nicht (da will ich nur meine eigenen
lokalen Artikel haben).

Gruß
Christian