Hallo, Am Wed, 24 Sep 2003, Al Bogner schrieb:

Am Dienstag, 23. September 2003 23:40 schrieb David Haller:

[Al, kannst du bitte da alle Attr-Zeilen stehen lassen, zu denen du noch Text zitierst? In diesem Fall also die, die ich eingefuegt hatte.]

...

...

Wie könnte man realisieren, dass nur neue / ungeprüfte News mit F-Prot bzw. Antivir nach fetchnews geprüft werden bzw. was bietet sich noch an Möglichkeiten an? [..] Allerdings hast du in der Form auch das Problem, dass wahrenddessen keine neuen News geholt werden sollten...

News werden hier per cronjob stündlich geholt, aber auch automatisch bei jedem Verbindungsaufbau.

Oehm. Jo. Da muss man mal testen wie lang so ein find laeuft (sooo gross ist der Traffic ja wohl nicht[1]) und ob's ueberhaupt stoert, wenn bei Variante 2 (unten) irgendwann das naechste fetchnews laeuft weiss ich nicht -- waere einen Versuch wert...

...

Das liesse sich aber evtl. ueber einen Umweg vermeiden (avnews.lastrun wird aktualisiert, bevor das find gestartet wird:

Variante2:

...

touch -r /var/state/avnews.lastrun /var/run/avnews.run date '+%s' > /var/state/avnews.lastrun find ...

Hier fehlt noch ein Test, ob .lastrun existiert... Naja, s.u.

...

Aber wie gesagt, da gibt's dann noch das Problem mit den atimes, da koennte man aber wohl auch drumrumbasteln (touch -c -a {-d,-r} + date -r)...

Einfacher waere es wohl, wenn du 'maxbytes = 140000' in die leafnode/config aufnimmst ;) Oder saugst du zuviel aus *.binaries.*?

Du denkst wohl an die aktuelle Virenwelle.

Auch. Wenn es nur darum ginge, dann waere das maxbytes die einfachste und sauberste Loesung.

Ich suche aber nach einer grundsätzlichen Lösung.

Klar. Hatte ich ja auch angedacht.

In MID <bkqcss$d27$4@joker.erwied.de> wurde vorgeschlagen:

[ -f stamp ] || touch -t 198001010000 stamp find /spooldir -newer stamp | xargs antivir touch stamp

Meine Shell-Programmierkenntnisse reichen aber nicht aus, um eventuelle Problematiken zu erkennen.

Das ist ja nix anderes als das, was ich schon vorschlug. Und da gibt's eben Probleme mit der Art, wie leafnode erkennt, ob eine Gruppe gelesen wird. Ich bin mir jetzt im Detail nicht sicher, wie das genau laeuft. <nachdenk mode="laut"> Was einfach zu implementieren waere, aber den Nachteil hat, dass keine Gruppen automatisch abbestellt werden... Evtl. liesse sich das mit dem (auskommentierten) tar loesen, aber das geht nur gut, wenn inzwischen niemand eine neue Gruppe abonnieren will... Ich bin mir jetzt nicht sicher, wie leafnode das handhabt, aber es koennte sein, dass es auch so gut geht, d.h. dass nicht alle Gruppen auf "abonniert" gesetzt werden... </nachdenk> ==== avnews [ungetestet!!!] ==== #! /bin/sh ### start config STATE_FILE="/var/state/avnews.lastrun" STAMP_FILE="/var/run/avnews.run" SPOOL_DIR="/var/spool/news" GROUPS_DIR="${SPOOL_DIR}/interesting.groups" GROUPS_FILE="/var/run/avnews.groups.tar" EXPIRE_NEWS="texpire" ### oder wie das inzwischen heisst... AVCHECK="antivir --allfiles -z" PRUNE_PATHS="active.read|interesting.groups|leaf.node|failed.postings|out.going|message.id" ### end config # PRUNE_PATHS in grep-regex umwandeln PRUNE_REGEX="`echo \"$PRUNE_PATHS\" | sed 's/\./\\\./g;s/|/\\\\|/g;s/^/\\\(/;s/$/\\\)/;'`" test -f "$STATE_FILE" || date '+%s' > "$STATE_FILE" # ### ACHTUNG: Fette "Race-Condition" (Teil 1)!! # # interesting.groups sichern # tar -c --atime-preserve -f "${GROUPS_FILE}" "${GROUPS_DIR}" touch -r "${STATE_FILE}" "${STAMP_FILE}" date '+%s' > "${STATE_FILE}" ls /var/spool/news/ | grep -v "$PRUNE_REGEX" | while read dir do ## Achtung: Annahme die Dateinamen sind normal und mind. ohne ## Zeilenumbrueche, wovon wir aber bei 'nem leafnode-spool wohl ## ausgehen duerfen... find "$dir" -type f -newer "${STAMP_FILE}" -print | while read fname do $AVCHECK "$fname" ret=$? if test $ret = 1 || test $ret = 101 then # Virus found! rm -f "$file" ### oder was auch immer ### Problem: leafnode macht hardlinks nach ### ${SPOOL_DIR}/message.id und bei x-posts auch in die ### jew. anderen Gruppen... Dieses script sollte die links ### in den Gruppen finden (und erneut auf Viren checken! ### *seufz*) und AFAIK muesste das naechste $EXPIRE_NEWS ### die verwaisten links in message.id aufraeumen... ### Ansonsten: msg-id aus news extrahieren und selber ### loeschen... fi done done # ### ACHTUNG: Fette "Race-Condition" (Teil 2)!! # # interesting.groups zurueckspielen # rm -rf "${SPOOL_DIR}/interesting.groups/" # # interesting.groups zurueckspielen # tar -x --atime-preserve -f "${GROUPS_FILE}" # Aufraeumen rm -f "${STAMP_FILE}" $EXPIRE_NEWS ==== Die "Problematik" liegt einfach in der Art, wie leafnode "erkennt", ob jemand eine Gruppe liest/abonniert... Daher uebrigens auch das von mir oft gepredigte (im Unterschied zu (aelteren Fassungen?) von "maddin_kopieren" in der SDB): cd QUELLE; tar cp --atime-preserve . | \ ( cd ZIEL; tar xp --atime-preserve; ) um Verzeichnisse von einer Partition auf eine andere zu kopieren... Denn wenn ohne "--atime-preserve" ein leafnode-spool kopiert wird, gibt's beim naechsten "fetchnews" eine Ueberraschung... HTH, -dnh PS: Melde dich (ggfs. auch per PM), wenn du noch Fragen hast bzw. Hilfe beim ausfeilen hast -- wie erwaehnt, obiges ist nicht getestet(!). Ich hab nur ein paar einzelne Dinge (wie den find-Aufruf) mehr oder weniger angetestet. [1] selbst ein "updatedb" (also ein 'find / ...') laeuft bei mir ueber 88489 MB "nur" 30min oder so ;) Dein news-spool wird dann doch etwas kleiner sein, oder bist du unter die ISPs mit "Full-Feed" von "*.binaries.*" gegangen? -- Time is an illusion; lunchtime, doubly so. -- Ford Prefect

Hi Al, Al Bogner schrieb:

Weiß keiner wo man das automatische Holen der News bei Verbindungsaufbau abstellt? AFAIR ist das erst seit 8.x so.

Also jetzt muss ich aufpassen das ich nicht am frühen Morgen schon wieder verbal entgleise, das ist sowas von einem Missfeature,das lässt sich kaum in Worte fassen. Die Windowisierung von SuSE manifestiert sich darin aufs Deutlichste. Hier wird tatsächlich eine Art dienst lediglich dadurch aktiviert das man zb. uucp oder news konfiguriert (fetchmail im Übrigen auch). Ich hatte zu einem speziellen Test auf so einer Maschine (8.2) - an die ich im Übrigen auch nicht mehr so leicht heran kam - ein uucp (von Hand ausm kopf so wie ich das immer mache) konfiguriert und mich gewundert warum ich plötzlich auf der eigentlichen uucp büchse von meinem uucp fast keine Daten mehr bekam. Bis ich rausgefunden hab das meine daten plötzlich alle auf dieser Mühle landeten. Frag nicht wie lange ich gesucht hab bis ich alle Verdächtigen (cron, stratscripte) abgetestet hatte, ich hab den Fehler natürlich zuerst bei mir gesucht. Dafür müsste man schon fast Schadenersatz verlangen. Es gibt eine Variable die leider nicht per default aus dem ifcfg.template übernommen wird, mit namen # This options defines whether the script /etc/ppp/poll.tcpip is run after # connecting to the internet via a dialup connection or not. The script # itself calls various jobs like fetchmail, fetchnews and sendmail. # Default to yes RUN_POLL_TCPIP= die musst du in das entspr. ifcfg kopieren und auf no stellen, der Dafault ist schwachsinnigerweise yes. am sichersten ist im ip-up den aufruf poll.tcpip auszukomentieren, da musst du aber aufpassen das dir das wieder einfällt falls ein update für das ip-up kommt. Hier wird eklatant vom Grundsatz "aktiviere keinen Dienst per default der nicht zum eigentlichen betrieb des Rechners notwendig ist" abgewichen. Ich kann mich auch an keine SuSEconfig mail erinnern die mich jemals vor diesem Missfeature gewarnt hätte. Gut gemeint ist halt in aller Regel das Gegenteil von gut! Auch wenn es 1000 daus durchaus geil finden könnten. btw: @suse warum gibt es dafür nur eine variable? warum zum Teufel kann man nicht jeden der 3 poll dienste einzeln ein und aus schalten? Gruss Falk