my life

Der dienstliche Hosting Provider hatte das Problem, daß eine Maschine die für uns einige Dinge überwachen sollte, über Monate hinweg eine konstant ansteigende Systemlast zeigte. Darauf hatte ich einige Male hingewiesen, denn durch die steigende Last ging die Vergleichbarkeit der Messwerte verloren. Nichts passierte.

Nun war die Maschine vor zwei oder drei Wochen an dem Punkt angekommen, an dem geschätzte 100% der Messungen in einem Timeout endeten, was natürlich endgültig nicht mehr tragbar war. Also beschloss ich letzte Woche, die Lösung des Problems etwas zu forcieren und unterbreitete den Vorschlag, man könne das System ja mal neustarten, um zu sehen, ob das hilft. Ich weiß nicht, was der Administrator beim Provider genau gemacht hat, aber die Systemlast ging auf jeden Fall daraufhin auf nahezu Null runter. Leider liefen unsere Messungen auch nicht mehr.

Ich hatte diese Woche wenig Zeit, deswegen bin ich erst heute dazu gekommen mal nachzufragen, was denn los ist. Man löste das Problem, allerdings war dann auch sofort die Systemlast wieder so hoch wie vorher. Der Administrator bestätigte mir, daß sie von dem Messprogramm verursacht wird, er aber keine Ahnung hätte wieso. (Er wollte das Problem sogar "durch die Blume" auf unsere langsame Applikation abwälzen, wo ich aber eindeutig intervenieren mußte.)

Wir waren also wieder am Anfang und ich guckte mir noch mal genau die restlichen Munin Graphen an, wobei mir auffiel, daß bei Memory (Beispiel) der Wert für den "slab cache" zum einen völlig unnormal hoch war, und zum anderen auch parallel mit der Systemlast schlagartig wieder angestiegen war. In der kurzen Erklärung im unteren Teil der Seite werden als Beispiel für den Inhalt u.a. Inodes genannt und auch eine schnelle Recherche bei Google brachte nichts gegenteiliges hervor. Gleichzeitig erinnerte ich mich an einen Artikel, den ich neulich für einen Bekannten rausgesucht hatte (aber gerade nicht mehr finden kann), der sich mit der Performance von Verzeichnissen mit sehr vielen Dateien unter Linux beschäftigte und das Ergebnis war grob zusammengefasst ein O(n) Graph, der damit auch genau zum Bild des Servers passte. Ich schlug also mal vor, daß man nach einem Verzeichnis mit sehr vielen Dateien suchen solle, auf das das Messprogramm zugreift. Und genau das war auch des Rätsels Lösung.

Das Programm legt temporäre Dateien an, räumt Sie aber aus unbekannten Gründen nach Abschluß der Messung nicht weg. So hatten sich in dem Verzeichnis über die letzten Monate rund 260.000 Dateien angesammelt, nach dessen Löschung nun alles wieder normal läuft.

Da sag' noch mal einer, durch zugucken kommt man nicht schneller zum Ziel.

Die Überschrift klang ansich relativ interessant. Also mal angeklickt, Artikel gelesen und festgestellt, daß das Produkt für mich nicht geeignet ist. Dann bin ich ins Forum zum Artikel gegangen, um mal zu sehen, wie die Poster das Produkt zerreißen. Nach den ersten zwei Threads hatte ich schon genug gelesen. Allerdings stach mir da noch dieser Thread ins Auge: leicht OT: BIND per DHCP-Server updaten?

Mit dem Thema hatte ich mich auch mal vor einiger Zeit beschäftigt. Ich wusste, daß das geht, denn ich hatte es schon gesehen - bei mir zuhause. Bei SuSE hatte das einfach ungefragt funktioniert. Allerdings existierte dieser Rechner nicht mehr, daher konnte ich nicht nachschauen, was ich dafür einstellen muß. Nach viel erfolglosem rumprobieren hatte ich, da auch kein Fortschritt zu erkennen war und der DHCPd sich standhaft weigerte auch nur die geringste Logmeldung zu dem Thema auszugeben, einfach aufgegeben.

Aber weg von der Geschichte, zurück zu Heise: Aus Erfahrung weiß ich, daß - so dämlich 98% der Nutzer der Heise-Foren auch sein mögen - immerhin geschätzte 0 - 2% dabei sind, die Ahnung haben und einem zumindestens einen Anstoß geben können, wonach man schauen kann - und so ist es auch in diesem Falle. Schon die erste Antwort hatte die richtige Information: "Dynamic DNS Updates"

Eine (sehr) kurze Google Recherche brachte mich zu DynamicDNS.pdf (ja, leider ein PDF). Ich habe ganz stumpf alles so eingestellt, wie im Beispiel und schon klappt es. Ich habe außerdem festgestellt, daß ich seinerzeit schon auf dem richtigen Wege war. Es fehlte quasi nur eine Option. Und dann habe ich mich bei weiterem Rumprobieren wieder weiter vom Ziel entfernt.. und dann klappte es irgendwann überhaupt nicht mehr, weil dann auch BIND noch gemeckert hat.

Merke: Wenn man in phpMyAdmin auf "Löschen" klickt, sollte man sich im daraufhin erscheinenden Warnhinweis zumindestens kurz angucken, was denn nun gelöscht wird.

Dann hoffen wir mal, daß das - zum Glück vorhandene - Backup auch funktioniert.

Wie schon bei Heise veröffentlicht, wissen sich die Spammer nun nicht mehr zu helfen. Sie greifen die Blacklists an, auf denen sie stehen.

So nun auch die ix.dnsbl.manitu.net, via dDoS.

wie gut, dass ich vor einigen tagen voellig entnervt wegen der (auch ohne ddos angriffe staendig auftretenden) timeouts dieser liste, mir eine eigene rbl mit fast identischem inhalt gebaut habe.
den inhalt der ix dnsbl kann man ja bei heise einfach herunterladen [1, 2]. speichert man diese daten dann wieder im favorisierten datenbanksystem ab, kann man sogar die tatsache umgehen, dass die textlisten etwas "kürzer" sind, als die von manitu betriebene rbl. die trefferquote ist dann in den letzten tagen auch erwartungsgemaess merkbar gestiegen...

was so ein kleines nicht geschlossenes socket doch ausmachen kann...
zur vorgeschichte: ich habe vor ca. drei wochen dnswl.org entdeckt und war einige tage erfolglos auf der suche nach einer möglichkeit, diese liste sinnvoll und effizient in meinen postfix zu integrieren. unter effizient faellt dabei fuer mich nicht die vom listenbetreiber vorgeschlagene technik die komplette liste regelmaessig runterzuladen, mit shellscripten umzuwandeln und dann von postfix mit dem cidr maptype ueberpruefen zu lassen. da, denke ich, hat mein rechner doch noch deutlich sinnvolleres zu tun, als 500× am tag die selbe liste durchzuackern... also habe ich mir einen kleinen policy server geschrieben, der einfach nur die client ip mit dnswl.org abgleicht und im trefferfalle ein OK liefert. keine grosse sache.. knapp 600 zeilen.
nach zwei tagen dauerbetrieb fiel mir mehr zufaellig auf, dass der speicherbedarf des daemons immer mehr zunimmt. zunaechst hatte ich einen fehler im dns package von tcl vermutet und mich schon auf lange debuggingsessions gefreut (...). zum glueck liess sich der fehler aber doch noch deutlich einfacher lokalisieren.. ich hatte noch bei der voranalyse zum debuggen bemerkt, dass in netstat noch eine ganze menge verbindungen auf dem von mir ausgewaehlten port im status CLOSE_WAIT verharrten.. das konnte so ja nicht richtig sein. ich war mir eigentlich sicher das socket korrekt zu schliessen, wenn die verbindung beendet werden sollte.. aber aus irgendeinem grunde hatte ich if not statt if geschrieben und die sockets blieben bis zum beenden des daemons offen.
nach ausbesserung dieses kleinen faux pas laeuft der daemon nun seit ueber einer woche mit gleichbleibendem speicherverbrauch. :)

als ich vor ein paar tagen gerade beim tunen der antispam massnahmen auf meinem mailserver war, habe ich dann auch gleich noch als unterstuetzende massnahme fuer meinen greylisting daemon policyd-weight installiert.
bislang hatte mich die aussage, dass policyd-weight hauptsaechelich fuer leute mit vielen vielen spams geeignet ist davon abgehalten.. die spams bei mir sind zwar nervig, aber als viele wuerde ich sie noch nicht bezeichnen. in der firma bekommen wir am tag spams im vier- bis fuenfstelligen bereich - das wuerde ich als viel bezeichnen. bei mir ists eher im durchschnitt zweistellig. wie dem auch sei: das konzept klang aeusserst interessant, daher hab ichs trotzdem installiert, und ich muss sagen, ich kann das teil uneingeschraenkt jedem weiterempfehlen.
in kombination mit greylisting und reject_unverified_sender kommt nun wirklich nahezu nichts mehr durch. und was es durch diese ganzen huerden schafft, wird dann noch von spamassassin geprueft... die zahl der mails die es bis dahin schafft ist allerdings erschreckend gering. dafuer sind aber auch nur <5% der mails die SA scannt wirklich spam, und diese werden dann mit einer (so gut wie) 100%igen trefferquote erkannt.

Nach Angaben der FreeBSD-Entwickler ist es unter bestimmten Umständen möglich, aus einem Jail auszubrechen.

toll.. vor nichtmal einer woche schwaermte ich noch einem kollegen vor wie sicher und toll doch jails seien.. und dann das. was ein glueck, dass man nur ein rc-script patchen und nicht gleich den ganzen kernel neu bauen muss..

weihnachtszeit, ferienzeit.. nachdem diverse renovierungsarbeiten in der wohnung erledigt waren, hatte ich mal wieder etwas zeit. mich hatte schon laenger die milter schnittstelle in postfix gereizt, weil es damit ja theoretisch moeglich sein muesste spam noch im smtp dialog abzuweisen, statt diesen erst nachtraeglich in spam ordner zu sortieren. als ich postfix seinerzeit installiert hatte, gab es die milter schnittstelle noch nicht.. als sie dann vor einem knappen halben jahr in den stable releases verfuegbar wurde, gab es noch keine ordentlichen anleitungen und es funktionierte auch noch lange nicht jedes milter programm mit postfix zusammen. es wurde also mal wieder zeit eine kleine recherche zu starten, was es so gibt und was funktionieren koennte. folgende programme habe ich finden koennen: MIMEDefang, milter-spamc, smtp-vilter und spamass-milter.

• MIMEDefang erschien mir fuer mein kleines vorhaben als etwas zu gross
• milter-spamc sieht ziemlich vielversprechend aus, scheint auch genau das zu koennen was ich brauche, ist aber leider nicht in den freebsd ports vorhanden, sonst waere das wohl das mittel meiner wahl geworden
• zu smtp-vilter habe ich keinen downloadlink finden koennen.. das programm scheint kommerziell zu sein und kann zudem auch wieder mehr als ich brauche
• bleibt also nur spamass-milter.. opensource, einfach zu findender downloadlink und es funktioniert angeblich auch mit postfix

also auf ans werk. der port laesst sich naturgemaess ziemlich einfach installieren und die tatsache, dass er sendmail vorraussetzt laesst sich dadurch umschiffen, dass im freebsd base system immer ein sendmail enthalten ist. nun ging es ans konfigurieren. nach etwas rumprobieren und googlerecherche haben sich die folgenden rc.conf eintraege als bei mir passend erwiesen..

spamass_milter_enable="YES"
spamass_milter_socket="/tmp/spamass-milter.sock"
spamass_milter_flags="-f -p ${spamass_milter_socket} -r 7 -m -a -- -u spamd"
spamass_milter_socket_owner="spamd"
spamass_milter_socket_group="postfix"
spamass_milter_socket_mode="664"

zeile 1: aktivieren
zeile 2: eigentlich unwichtig, aber alle meine sockets liegen in /tmp
zeile 3: -f = fork into background, -p sollte ersichtlich sein, -r 7 = ab 7.0 spampunkten mail rejecten, -m = mailbody nicht veraendern (wichtig, denn das kann die postfix milterschnittstelle nicht!), -a mail von smtp-auth verbindungen ignorieren ("WITH_ADDAUTH_PATCH=yes" beim compilen nicht vergessen) und -- (ab hier optionen an spamc weiterreichen) -u spamd = spamc unter dem user spamd starten, so ist das bei mir naemlich konfiguriert, da ich die meissten mails an virtuelle postfaecher zustelle, sprich keine wirklichen systemuser existieren
zeile 4: ist eigentlich egal, sollte nur ein gueltiger systemuser sein
zeile 5: das ist wichtig, denn sonst kommt postfix nicht an das socket
zeile 6: hier ist g+w wichtig, denn in der defaulteinstellung kann die gruppe nicht auf das socket schreiben - das waere hier postfix.

mein system ist leider nicht ganz so flott, daher musste ich im rc-script in zeile 38 noch ein "sleep 1" einfuegen, sonst war das programm noch nicht weit genug gestartet um das socket erstellt zu haben, wenn das script schon versucht die besitzrechte anzupassen. nun kann man spamass-milter starten.

jetzt muss man postfix noch mitteilen, dass er seine mails da durchzujagen hat. dazu traegt man in der main.cf folgendes ein:

smtpd_milters = unix:/tmp/spamass-milter.sock

wenn einen postfix danach mit derartigen meldungen beglueckt:

Dec 26 02:43:02 mailserver spamass-milter[4800]: SpamAssassin: st_optionneg[134600192]: 0x3d does not fulfill action requirements 0x13
Dec 26 02:43:02 mailserver postfix/smtpd[4773]: warning: milter unix:/tmp/spamass-milter.sock: can't read SMFIC_OPTNEG reply packet header:
Unknown error: 0
Dec 26 02:43:02 mailserver postfix/smtpd[4773]: warning: milter unix:/tmp/spamass-milter.sock: read error in initial handshake

dann muss man noch eine weitere zeile in die main.cf einfuegen:

milter_end_of_data_macros = b i j _ {daemon_name} {if_name} {if_addr} {mail_addr}

nun sollte alles funktionieren...
manchmal sieht man vielleicht noch diese meldung:

Dec 26 03:51:57 mailserver spamass-milter[19292]: Could not retrieve sendmail macro "i"!. Please add it to confMILTER_MACROS_ENVFROM for better spamassassin results

warum die kommt weiss ich nicht.. ich konnte sie auch nicht zuverlaessig reproduzieren, aber sie scheint den laufenden betrieb auch nicht zu stoeren.
nun hoffe ich, dass mein taeglicher spamreport (was so in den spam-ordner wegsortiert wurde) wieder etwas kuerzer wird.. der war in den letzten wochen naemlich leicht ausgeufert.

Das Faszinierende an Ubuntu ist die geschickte Kombination aus Debian GNU/Linux mit selbst entwickelten Features. Die Stärken von Debian - Stabilität, Community-Support und eine Riesenmenge einfach installierbarer Software - bleiben erhalten, die Debian-Schwächen - Releases mit schon bei Erscheinen veralteter Software, umständliche Installation und Konfiguration sowie die schlechte Vorkonfiguration speziell für den Desktop-Einsatz - werden hingegen beseitigt.

auf einem neulich angeschafften lenovo (ibm) laptop sollte linux installiert werden.. die spontane wahl fiel auf das derzeit beliebteste desktop-linux: ubuntu. als der laptop dann aber da war las ich in der c't, dass suse enterprise linux irgendwas dingsbums speziell auf diese modellreihe optimiert ist.. leider konnte ich auf die schnelle keine installations-cds finden (es ist ja legal sich diese cds herunterzuladen, man muss sie nur finden.. suse/novell selber bietet sie nich an), also wurde dann doch ubuntu installiert.
ich bereue es nicht. die installation ging aeusserst flott (ich hab zwar nicht auf die uhr geguckt, wuerde aber rund 20 minuten schaetzen) und problemlos (die windowspartition konnte einfach mit hausmitteln resized werden). das system funktioniert out-of-the-box sehr gut. selbst laptopspezifische dinge wie das runterfahren bei niedrigem akkustand und standby bei klappe zu funktionieren ohne weitere konfiguration. den grafikkartentreiber musste ich allerdings dann doch von hand installieren, da der nicht opensource ist.. aber selbst das ging per paketmanager.
alles in allem nur zu empfehlen.. und deren philosophie gefaellt mir auch.

wie bereits vor einigen tagen erwähnt, bin ich ja stolzer besitzer eines neuen mobilen telefons.
nachdem ich nun nach und nach alle einstellugen vorgenommen, standardfunktionen ausprobiert und daten eingepflegt hatte, wurde es langsam zeit auch mal die neuen features auszuprobieren.

vielbeworben wurde ja der javagestuetzte, pop3- und imap-faehige email client.. ich war geradezu entzueckt zu sehen, dass der client sogar ssl kann.. also munter meine zugangsdaten eingetragen, ssl angehakt, einen ersten abrufversuch gestartet und schon eine enttaeuschung. das telefon quittierte jeglichen versuch eine verbindung aufzubauen mit dem kommentar:

Zertifikat nicht vorhanden

die meldung macht in gewisser hinsicht auch sinn, denn ich benutze auf meinem mailserver keine zertifikate einer öffentlichen CA, sondern habe mir eine eigene gemacht. die ist natürlich nicht in der telefonsoftware installiert. mein ca-zertifikat zu besorgen ist natuerlich auch kein problem.. aber es ist enorm schwierig herauszufinden, wie man das zertifikat installiert bekommt. ich habe 1,5 stunden mit dem durchsuchen des handbuchs (in dem mal so ca. ueberhaupt nichts interessantes zum thema ssl und zertifikate steht) und verschiedenen foren zugebracht. offensichtlich gibt es zu viele java programmierer auf dieser welt.. und sie machen sich alle samt darueber gedanken, wie sie ein eigenes zertifikat mit code-signing berechtigung in ihr handy bekommen. nokia scheint in der 3rd edition der series 40 software naemlich code-signing bei benutzerzertifikaten verboten zu haben. das war aber ja gar nicht mein problem, denn ich musste erstmal das zertifikat in das handy bekommen, um ueberhaupt in dieses auswahlmenue, was das zertifikat denn koennen duerfen soll zu kommen. nach besagten anderthalb stunden bin ich endlich auf einen forenbeitrag gestossen der mich zu dieser anleitung gebracht hat. dort wird das ganze prozedere zwar auch zum zweck der signierung von java applikationen beschrieben.. aber die seite enthaelt den entscheidenden hinweis:

Important! You can install certificates ONLY in DER format [...]

darauf muss ja auch erstmal einer kommen. jedes andere programm kommt mit zertifikaten im PEM format zurecht.. nur handys nicht. nach diesem hinweis habe ich mir noch schnell von dieser seite den befehl

openssl x509 -outform der -in cacert.pem -out cacert.cer

zum konvertieren einer PEM datei in eine DER datei abgeguckt.. und nun liess sich das zertifikat auch problemlos im handy installieren. erwartungsvoll dachte ich, ich koennte endlich meine emails lesen... aber da war ich ein wenig zu voreilig. jetzt funktionierte zwar der verbindungsaufbau per IMAP, aber gemeldet wurde immer "0 emails" - was nachweislich nicht den tatsachen entsprach.

also den non-ssl port geoeffnet, den client umkonfiguriert und den packet sniffer angeworfen. nach einigem recherchieren und vergleichen mit anderen clients habe ich herausgefunden, dass der nokia client kein

a select inbox

sendet.. der imap server antwortet daraufhin mit einem fehler, das handy denkt es waeren keine neuen mails da und beendet die verbindung. eine loesung fuer das problem habe ich nicht finden koennen.. aber der pop3 client scheint zu funktionieren - und da er die emails beim abruf nicht vom server loescht, wird das wohl reichen muessen.

dann waere da noch die andere sache: emails verschicken. mittlerweile erwartete ich fast schon, dass das nicht klappt.. und meine erwartungen wurden auch nicht enttaeuscht. der client kann kein "starttls", sondern nur smtps. nach all den vorherigen problemem war das aber das am einfachsten zu behebende - einfach die smtps zeile in der master.cf von postfix aktivieren, port in der firewall freischalten und los gehts. und erstaunlich oder nicht - es klappte.. die versendeten emails kamen tatsaechlich beim empfaenger an.

jetzt frage ich mich nur.. nutzt ueberhaupt irgendjemand diese email features in handys? macht sich von diesen leuten irgendjemand gedanken ueber sicherheit? offensichtlich nicht.. denn sonst gaeb es wohl mehr anleitungen zum konfigurieren der clients. oder die clients ansich waeren besser.