sysadmin - 5.11.2002 - 16.12.2002

mehr Viren

mehr Viren. Von News.com: E-Mail-Viren verdoppelten sich im Jahr 2002. Und das, mit MS's angeblichem neuem Fokus auf "Sicherheit". Na ja. Gut, dass andere virusfreie Lösungen kommen :-).

[über Abort, Retry, Fail?] Ja, sieht so aus, als hätte Microsoft bei ihrem Sicherheitsfokus wirklich Erfolg gehabt - besonders IE und OE sollten verbrannt, in die Luft gesprengt und aus der Realität gezogen werden. Bitte.

Aber es wird nicht passieren, fürchte ich. Stattdessen werden sie noch mehr Scheiße produzieren und es .NET nennen und noch mehr Zeug wird bozo gehen.

Gefunden bei Abort, Retry, Fail?.

Beitrag ohne Titel

It's a deligt to just switch off and configure out borken NT machines, when they go bozo. Ok, usually we try to repair stuff, but since the machine that broke down twice today is the last NT based machine in our production environment, I wasn't that keen on getting it back to work. So I just swiched the last three shops running on that box to dummy pages, unconfigured everything monitoring this POS and am done with it. On monday the shops are transferred to a newer box on linux.

But there is still a question: when a machine has automatic memory error discovery and automatic bank disabling, why can't this POS just do what it is expected to do and switch of the broken memory bank and go on? It worked the last time, why doesn't it work this time? Bah.

Einer der dümmsten Vorträge über Browser

Eine der dümmsten Vorträge über Browser - entschuldigen Sie bitte, aber diese Leute verstehen es nicht. Lesen Sie ihren kleinen Artikel, finden Sie mindestens 5 Fehler (dort gibt es viel mehr, aber wir wollen es einfach halten, nicht wahr?) und dann können Sie sie behalten. Das könnte wirklich lustig sein, wenn es nicht die Tatsache gäbe, dass sie ernsthaft dabei sind ... (gefunden durch den "Jürgen Möllemann Gedächtnis Bloq")

Beitrag ohne Titel

Seen on [ Scripting News]: A feature for a mail server?. >What if every mail server supported a new feature. An XML-RPC interface with one entry point. It takes one parameter, a user name and returns a struct containing a boolean. The boolean is true if there is such a user on that machine. It's a struct so more info can be returned later. My email program could send a message to the server each piece of mail came from. Hey you got someone with this name, and do they send out spam? If the answer is no, filter it to the bit bucket.

Nice idea, but it's already there. Ok, not "XML-RPC", but there are other formats out there and some are much older. You can use the SMTP VRFY command on many mail servers to verify a user. Problem: since user checking on many machines is very hard work (think about stuff like http://hotmail.com/ or http://gmx.de/ - multi-million-user sites!), so not every host supports it, many hosts don't allow VRFY to not give out too much data (since Spammers can use this interface to check addresses for legimity, too!) and some only give you a OK on every check (for the same reasons, they just hide better).

So would it solve the problem at hand? No. Spammers would just start to use the very same interface to validate their own email lists and use one picked randomly out of the pool of their addresses as the sender. What would we get? Nothing better than now, only better disguised. You have to take into account that spammers do learn, too. They might be at the bottom of the social behaviour on the net, but they are not necessarily stupid. >Maybe I'm missing something or it's too early in the morning, but couldn't we ask the servers if they know about this person sending me the spam. I have a feeling that most of the spam I get comes from made-up people. Oh, sure they are. They are for some time now. Spammers are not interested in response . One of the most important things to note. Spammers don't care for email replies. They actually don't care for the recipient at all - all they do is send out mail, that's all. They are payed for that. There might be click-throughs (most of porn spam is to get people to click the links in the mail, that's why most porn spam nowadays is HTML with embedded images). But nobody in that business want's you to return anything to the sender. So what to do about spam? The curently best practice is to set up a bayesian mail filter like bmf or any of the like projects. There are some to integrate into mail clients, some to integrate into the mail server. Just watch out for them. I use bmf to filter mail on my server and it works quite good after feeding it several hundred mails and it get's better every round. False positives are down to only 2-3 a day (and mostly administrative stuff that is easily spotted in the spambox) and false negatives is down to 5-7 a day, easily spotted in the prefiltered inbox, too. The vast majority of about 70-80 spam mails per day are filterted out just fine.

Gefunden bei Scripting News.

Beitrag ohne Titel

Was ist falsch mit Joshua Allens Kommentar zu yEnc? Eine einfache Sache: yEnc versuchte, ein Problem auf eine Weise zu lösen, die nicht stabil ist: Es gibt bereits implementierte Standards für die Kodierung, aber yEnc ignoriert sie alle und setzt sein eigenes oben auf NNTP und Netnews. Es ignoriert alle bestehenden RFCs und erfindet das Rad neu.

Wird dies Dinge brechen? Sicher, es hat es bereits getan. Nicht jeder springt auf den Wagen, um yEnc zu implementieren, sodass die Menschen externe Tools verwenden müssen, um an die Dinge zu gelangen, die sie wollen. Aber da yEnc auf die schlechteste mögliche Weise implementiert wird, wird dies nicht immer funktionieren. Nehmen Sie zum Beispiel eine bi-charset-Umgebung wie das Mac OS. Sie verwenden normalerweise Mac-Zeichensätze extern, sprechen aber latein1 oder andere Standard-Zeichensätze auf Protokollebene. Ihre Daten werden also von einem Zeichensatz in den anderen konvertiert. Da yEnc Anwendungen, die nichts über yEnc wissen, keinen Hinweis auf seine Existenz gibt, wird das Zeug kaputt gehen.

yEnc macht fast alle Fehler, die UUENCODE gemacht hat, aber fügt mehrere Schichten seiner eigenen Fehler hinzu. Das ist einfach nur dumm. Und dass es "funktioniert" ist kein Grund - es funktioniert in dem Maße, dass Menschen, die yEnc-fähige Programme verwenden, Informationen austauschen können. Aber die Grundidee des Internets ist es, so vielen Menschen wie möglich zu ermöglichen, etwas zu nutzen. Deshalb ist MIME so kompliziert, seine Idee ist es, Marker im Voraus zu setzen, damit Programme wissen, dass etwas Problematiques vor ihnen liegt, auch wenn sie nicht wissen, was es tatsächlich ist - und es an eine Hilfsanwendung weiterzugeben.

yEncs dumme Idee von Body-Tags macht diese automatische nach vorne kompatible Art und Weise, mit Dingen umzugehen, problematisch.

Eine sehr gute Diskussion über die Probleme von yenc finden Sie unter http://www.exit109.com/~jeremy/news/yenc.html - lesen Sie es, verstehen Sie es und Sie wissen, was mit Johns kleiner Rede nicht stimmt.

Beitrag ohne Titel

Wenn alles funktioniert, sollte dies auf lifejournal und in meiner eigenen Sysadmin-Ecke erscheinen und mir das Leben erleichtern, da ich nur ein System bearbeiten muss, um Beiträge auf mehrere Hosts zu replizieren. Footbridge regiert.

Beitrag ohne Titel

I hate borken mail servers and mailfilters going postal. Today bmf played up on me and trashed some mail. Of course there was bound to be some interesting content in there, but I don't know, since I can't read them. fsck. So bmf is out again. But how to get rid of spam? At least bmf filtered enough of the shit out so I didn't have to wade through them all by hand. Now I have to set up some redirection to only filter stuff that's probably spam to protect important mails. Damn, that's bound to be work.

Beitrag ohne Titel

ObStupidProgrammers: start/stop scripts that check for existance of a pid file but not wether the contained pid actually is still running or just left over from a crash ...

Beitrag ohne Titel

People taking their notebook out of the network to go on journey and not only take their notebook but their cabling adapter and terminator for the 10base2 network with them should expect network troubles. And please don't blame them on the firewall ...

Beitrag ohne Titel

Setting up a virtual host with Apache for a Python Community Server with Manila-style hostnames (one host for each server) is quite easy:

set up your domain to have a wildcard A record for the domain of the server

set up your apache to have a virtual host with a "ServerAlias *.doma.in" in it

add a ProxyPass rule for the new server where you rewrite / to become http://pycs.server.doma.in:5445/~~vhost~~/%{HTTP_HOST}/

enable the rewriting rules in rewrite.conf for PyCs so it recognizes those addresses

That's it. Run it. Have fun.

Beitrag ohne Titel

Squid overdid it today when all those rules from yesterday didn't work and squid again went on caching files. So now it is replaced by apache. And guess what? It works as expected ...

Beitrag ohne Titel

Squid hat mich wieder geärgert. Wieder einmal. Ich hatte das Erlebnis, dass Squid Server pingt, obwohl es das nicht tun sollte. Ok, ärgerlich, aber man kann damit leben (obwohl es von Zeit zu Zeit Timeouts verursacht).

Ich kann damit leben, dass Squid Anfragen zwei- oder mehrmals sendet, obwohl es wirklich keinen Grund dafür gibt - es scheint, als ob die interne GET-Verarbeitung durcheinander kommt, wenn auf der Browser-Seite ein Timeout auftritt.

Aber was mich wirklich auf die Palme gebracht hat, war die dumme HEAD-Handhabung. Es cached HEAD-Anfragen. Ja, dumme Idee, sie wurden ursprünglich für bandbreiten sparende Anfragen erfunden. Sie sollen rausgehen und den Server überprüfen und nicht gecached werden, weil wenn das Dokument sich nicht geändert hat, der Client es nicht abrufen muss, aber es muss wissen, ob es sich geändert hat.

Ok, richte eine ACL-Regel für HEAD-Methoden ein und setze sie auf no_cache (eigentlich, was für ein hirnloser Idiot hat die "no cache deny ACL"-Syntax mit ACLs erfunden, die Seiten beschreiben, die tatsächlich nicht gecached werden sollen? Das ist zweimal rückwärts!). Sollte funktionieren. Funktioniert nicht. Wenn es vorher eine GET- oder POST-Anfrage gab, liefert ein HEAD Daten aus dem Cache, obwohl es auf no_cache gesetzt wurde. Dumm. Schlecht. Hässlich.

Also musste ich eine zusätzliche Regel einführen, um nur die GET-Anfragen zu unterdrücken, die zu schlechten HEAD-Anfragen führen könnten (glücklicherweise war dies möglich, weil ich Probleme mit AmphetaDesk und seinen Updates hatte und AmphetaDesk den Browsernamen ausfüllt). Also cache ich jetzt keine HEAD-Anfragen und keine Ergebnisse für AmphetaDesk. Funktioniert es? Nicht wirklich, wenn es noch Dokumente im Cache von Squid gibt, liefert es HEAD von diesen Dokumenten, unabhängig von der Konfiguration. Verdammt.

Also musste ich sie entfernen. Dafür ist doch die PURGE-Methode da, oder? Falsch. PURGE löscht nur Dokumente, nicht gecachte Header. Also muss man zuerst das Dokument abrufen, dann es löschen, um seine gecachten HEAD-Anfragen zu entfernen. Oh-mein-Gott.

Und jetzt habe ich immer noch einige TCP MEM HIT im Log, obwohl es nicht cachen sollte. Es scheint, als ob es das Memory-Caching anders als das Disc-Caching handelt. Oh, und dies ist reproduzierbar mit 2.2 und 2.4. Verdammt. Mistkerl.

Könnte das Leben nicht eigentlich einfacher für Sysadmins gemacht werden? Bitte?