Posts mit dem Label bugs werden angezeigt. Alle Posts anzeigen
Posts mit dem Label bugs werden angezeigt. Alle Posts anzeigen

Dienstag, 2. November 2010

RANT: Wer darf heutzutage eigentlich Mailserver betreiben?

Mir platzt hier gleich die Hutschnur. Man ist mal eine Woche zum Entspannen (und wegen einer Tagung)) aufs Land gefahren, und dann ist man andauernd am Server fixen. Arrgh.

Ein Drama in drei Akten

Dass einer meiner Server am Sonntag (natürlich während des gemütlichen Abendessens bei der Familie) wegen zu wenig RAM ausstieg ist ja meine Schuld, aber was dann gestern und heute sonst noch passierte muss ich einfach mal loswerden.

1. Akt: Die Uni

Gestern Abend hatte die Uni Probleme. Ausnahmslos alle Emails wurden mit einem permanenten Fehler abgewiesen:

 ...
 host localhost [127.0.0.1]: 
   550-Mailbox unknown. Either there is no mailbox associated with this
   550-name or you do not have authorization to see it.
   550 5.1.1 User unknown

Das ist natürlich genial für Mailinglisten - von denen fliegt man dann in der Regel runter - aber auch, wenn man wie ich bei seinem Hoster diese Adresse angegeben hat (weil unabhängig von den Systemen die man dort hosted) und dann die Rechnung oder Trafficabrechnung einen User unknown rauswirft.

Natürlich war gestern der Monatserste und natürlich hat mein Hoster mir versucht an diesem Tag die Rechnung und die Trafficabrechnung zu schicken. Die Trafficabrechnung ist angekommen. Die Rechnung (noch?) nicht.

2. Akt: Der Ticketversender

Ich bin diese Woche weggefahren, weil ich am Donnerstag zu einer Tagung will. Dazu braucht man natürlich ein Ticket. Und wie bekommt man das? Richtig, über einen Dienstleister. Dazu meldet man sich dort an, bezahlt das Ticket und wartet auf das pdf mit dem Ticket.

Und wartet. Und wartet. Und schreibt eine Email an den Support.

Denn: zum Passwort ändern auf der Plattform muss man eine Email bestätigen, aber die kommt ebenfalls nicht an.

Nun bekam ich dann heute eine html-only Email, dass das Ticket nochmal versendet wurde. Aber es kam nicht an, dafür füllte sich mein Maillog:

postfix/smtp[18334]: connect to mail2.amiando.com[213.183.6.102]:25: Connection refused
postfix/smtpd[18137]: NOQUEUE: reject: RCPT from mail.amiando.com[195.71.125.161]: 
  450 4.1.7 <no-reply@mail.amiando.com>: Sender address rejected: unverified address:
      Address verification in progress; from=<no-reply@mail.amiando.com>
      to=<xxxxx@XXXXXXXXX> proto=ESMTP helo=<lnxp-1930.srv.mediaways.net>

Die HTML-Mail löste bei mir leichte Übelkeitsgefühle aus, aber als ich den Eintrag im maillog auswertete wurde mir irgendwie schlecht.

Diese Leute versenden Emails und wundern sich, dass sie als SPAM erkannt wird?

Fassen wir mal zusammen:

Die Email ist HTML-Only, die Absenderadresse existiert nicht, so dass sie bei Fehlzustellungen nichts davon bemerken - deren System wird es also immer wieder versuchen, an eine nicht-funktionierende Adresse von einer ebenfalls nicht-funktionierenden Adresse aus mails zu versenden. Damit macht man sich bei den postmastern, die diese Bounces bekommen, so richtig beliebt.

Dann meldet sich der Mailserver mit dem Namen lnxp-1930.srv.mediaways.net obwohl er laut DNS eigentlich mail.amiando.com heissen sollte. Noch ein SPAM-Kriterium.

Und zur Kröhnung schreiben sie einen Mailserver in ihre Zone, dessen SMTP-Port Verbindungen ablehnt.

3. Akt: Services die verbinden...

Mit dem Spruch wirbt eine andere Firma für ihre Dienste. Leider scheint es damit nich so weit her zu sein. Ich bekomme hier jedenfalls Emails von der Adresse www-data@int3.web.int.fra.privatnetz.org

Mein Mailserver scheitert dann laut syslog aber daran, wenn er versucht mails an die IP 10.1.1.100 zuzustellen.

Die haben doch allerernstes sowohl hostnamen mit privaten IPs in ihrem DNS, als auch MX-Records die auf private IPs zeigen! Stümper! Das ist 'pollution of the public namespace' was den DNS angeht und auch sonst einfach nur kaputt.

Und dann wundern sich Leute, warum ich NAT und Masquerading hasse!

Das Ergebnis ist dasselbe wie oben: Sie werden niemals Fehlermeldungen erhalten und vielfach als SPAMMER erkannt werden.

Fazit

Ich frage mich langsam echt, ob wir einen Internet-Führerschein brauchen - für Diensteanbieter!

Freitag, 28. Mai 2010

How to disable AAAA queries for IPv6 / configure your resolver

Today I stumbled upon a very nasty behaviour of glibc - again.

On a host which has no access to IPv6 at all and no module-support in the kernel, it seems the connect() call fails when there is a AAAA record in place for a remote server.

This means I cannot wget a webpage if an AAAA record exists for the page, etc.

You will find many solutions on how to 'disable IPv6' - but they all miss the resolver in glibc, the part that is behind the 'gethostbyname' call.

I like to disable AAAA DNS-queries for IPv6 completely - and the solution is easy:

#cat /etc/resolv.conf 
options no-inet6
nameserver ...
nameserver ...

Just documenting it here, because the manpage does not document the 'no'-Feature and searching for this on google was not helpful at all.

Dienstag, 18. Mai 2010

bzip2 vs. gzip und gvfs im Allgemeinen

Eben bin ich mal wieder über einige Kleinigkeiten gestolpert, die einfach nur ärgerlich sind.

Ein paar wirklich kleine Bugs, aber trotzdem unendlich nervig!

Gnome bindet Samba-Freigaben (also Windows-Freigaben) innerhalb des virtuellen Dateisystems ~/.gvfs innerhalb des Homes des Nutzers ein. Soweit so gut.

Erster Akt: Zugriff!

Man könnte ja annehmen, dass Gnome dann auch transparent Zugriff darauf erlaubt. Wenn ich ein Terminal starte, kann ich in das Verzeichnis wechseln und mit normalen Kommandozeilentools auf die Freigaben schreiben. Alles toll.

Aber in Gnome tauchen diese Freigaben im normalen Datei-öffnen Dialog nicht auf. Entsprechend auch nicht in Firefox, Galeon, Epiphany. Wie soll denn ein Endnutzer jetzt auf einfache Weise einen Download auf dem Share speichern? Vielleicht übersehe ich auch was, aber sowas ist einfach nur ärgerlich. Nicht nur weil das unter Windows ohne Probleme funktioniert.

Navigiert man manuell nach ~/.gvfs/ klappt es aber...

Zweiter Akt: Verknüpfungen

Wer es aus Windows kennt, versucht es auch unter Linux. Hat man nach viel Suchen die richtige Freigabe auf dem richtigen Server gefunden, zieht man die Freigabe aus der Netzwerkumgebung auf den Desktop und hat fortan eine Verknüpfung mit dem Share, die beim Doppelklick wiederhergestellt wird.

Nicht so bei unserem Lieblingsfrickelbetriebssystem mit Gnome. Zuerst beschwert es sich, dass die Freigabe kein normaler Ordner ist. Ach! Dann legt es auf dem Desktop einen leeren Ordner mit dem Namen der Freigabe an. Toll! Wie soll denn ein Endbenutzer jetzt auf die Idee kommen, dass alles was er in diesem Ordner speichert eben nicht auf dem Server landet?!

Nun gut, versuchen wir Rechtsklick auf den Freigabenamen in der Netzwerkumgebung, dann Verknüpfung erstellen. Ooops. Ich habe auf der obersten Ebene des Servers ja keine Schreibrechte, also Fehlerdialog, Verknüpfung kann nicht angelegt werden. Leider erfolgt auch keine Möglichkeit wie bei Windows (sic!) die Verknüpfung statt dessen direkt und automatisch auf dem Desktop anlegen zu lassen. Ergo: Verknüpfungen erzeugt man manuell, indem man einen Starter mit dem Ziel nautilus smb://server/ anlegt.

Wie soll denn ein Endbenutzer....

Wenn man viel Glück hat geht das auch meistens. Oft habe ich aber wie unter Windows nur leere Servereinträge, bekomme skurrile dbus-Fehlermeldungen, kann das Netzwerk nicht durchsuchen, etc. Ja, iptables ist leer und auf ACCEPT.

Dritter Akt: Auf der Kommandozeile ist alles besser?

Nein, nicht wirklich.

Bei dem Gnomefs ist z.B. die Funktion fchmod nicht implementiert. Und das führt zu unnötigen Fehlern.

Situation: Auf dem Share liegt eine Datei, die wir komprimieren wollen.

Also Kommandozeile, cd ~/.gvfs/sharename ; bzip2 file - und wir bekommen einen netten IO-Error um die Ohren gehauen. Vorher hat bzip2 das File übrigens ordnungsgemäß komprimiert. Komplett. Und wieder aufs Share geschrieben. Dann gelöscht.

Das gleiche Experiment mit gzip: Es wird auch ein Fehler geworfen, das File wird aber korrekt abgelegt und die Quelle gelöscht.

Welches Verhalten ist nun besser? gzip, der die Rechte nicht setzt und dem es egal ist, oder bzip2, dass die Datei einmal übers Netz zieht, komprimiert, schreibt und zurücksendet und dann löscht?

Was mich aber am meisten wundert: warum wird das fchmod erst NACH dem Schreiben der Nutzdaten gemacht?

Die Krönung des ganzen: Der Mode, den bzip2 hier übergeben will, unterscheidet sich nicht vom Mode, den die Datei auch so schon hat, wenn sie neu angelegt wird -.-

Fazit: Alle doof außer Mutti!

Montag, 22. März 2010

Presenter-Keyodes mappen

Was tun, wenn die Software zum Blättern die Cursortasten 'Links' und 'Rechts' verlangt, der Presenter aber nur die Bild auf und Bild ab Tasten als Keycodes sendet?

Die Frage wurde mir vorhin in einem telefonischen Notruf 5 Minuten vor Beginn einer Präsentation gestellt... Damit es beim nächsten Mal schneller geht hier die Doku.

Nun, zunächst sucht man per xev die Keycodes der betreffenden Tasten und xmodmap -pr die Namen der Zieltasten.

Man erhält dann sowas:

TasteKeycodeName in X
Bild auf 112 Prior
Bild ab 117 Next
Links 113 Left
Rechts 114 Right

Und nun mappen wir fröhlich die Tasten um:
Bild auf soll Cursor links werden:
xmodmap -e "keycode 112 = Left"
Bild ab soll Cursor rechts werden:
xmodmap -e "keycode 117 = Right"

Und wenn man Ersatz für die Cursortasten will:
Links soll Bild auf werden:
xmodmap -e "keycode 113 = Prior"
Rechts soll Bild ab werden:
xmodmap -e "keycode 114 = Next"

Freitag, 12. März 2010

Unter OpenWRT per DHCP den NTP announcen

Wer sich wundert, warum die Rechner zu Hause den NTP-Server des eigenen Routers einfach nicht benutzen wollen, sollte mal per tcpdump nachsehen, ob die DHCP-Option 42 auch gesendet wird... Wenn nicht muss man auf dem Router in der /etc/config/dhcp das Schlüsselwort dhcp_option benutzen:
config dhcp lan
        option interface        lan
        option start            100        
        option limit            150
        option leasetime        1h
        list dhcp_option '42,10.1.1.1'
Hier wird den Clients im LAN mitgeteilt, dass man 10.1.1.1 als NTP-Server nutzen will...

Dienstag, 9. März 2010

IO-Durchsatz und kernel neuer 2.6.28

Kurze Notiz: Wer auch wie ich das Problem hatte, dass manche Anwendungen wie liferea das gesamte System einfrieren lassen, wenn sie ein bischen IO machen (eine sqlite-db nutzen z.B.) kann ich ein downgrade auf Kernel 2.6.28, z.B. 2.6.28-gentoo-r5, empfehlen. Seitdem ich von 2.6.33 umgestiegen bin, kann ich wieder Multitasking machen und liferea benötigt keine 20-30 Sekunden pro Artikel(!) zum Darstellen, wenn mal ein Bild enthalten ist. Auch insgesamt ist das System wesentlich responsibler geworden und damit wieder benutzbar. Das Problem als solches stellte sich durch 80-90% iowait dar - so dass ich trotz Dualcores nicht mehr arbeiten konnte, weil der IO Scheduler das System schlicht und einfach komplett lahmgelegt hat. Ich hoffe das wird mal wieder besser *seufz*

Montag, 9. November 2009

Things you don't want to see when creating a filesystem...

Wo wir schon beim Thema sind. Habe eben ein altes kernel-log auf meinem nas gefunden:
BUG: unable to handle kernel NULL pointer dereference at 00000004
IP: [] mempool_free+0xe/0x97
*pde = 00000000 
Oops: 0000 [#1] PREEMPT 
Modules linked in: xfs raid456 async_xor async_memcpy async_tx xor md_mod dock container video output wmi ohci_hcd nfsd auth_rpcgss exportfs ac battery ipv6 nfs lockd nfs_acl sunrpc loop parport_pc parport floppy pcspkr rtc i2c_i801 i2c_core rng_core button intel_agp agpgart evdev ext3 jbd mbcache cbc dm_crypt crypto_blkcipher dm_mirror dm_snapshot dm_mod ide_generic ide_cd_mod cdrom ide_disk sd_mod usb_storage dc395x 3c59x mii scsi_mod piix ide_core ehci_hcd uhci_hcd usbcore thermal processor fan

Pid: 27646, comm: md0_raid5 Not tainted (2.6.25.1 #3)
EIP: 0060:[] EFLAGS: 00010286 CPU: 0
EIP is at mempool_free+0xe/0x97
EAX: cf5f15a0 EBX: 00000000 ECX: c15f7990 EDX: 00000000
ESI: 00000000 EDI: cf5f15a0 EBP: 00000000 ESP: cf77be20
 DS: 007b ES: 007b FS: 0000 GS: 0000 SS: 0068
Process md0_raid5 (pid: 27646, ti=cf77a000 task=cf484b00 task.ti=cf77a000)
Stack: ...
Call Trace:
 [] return_io+0x2b/0x33 [raid456]
 [] handle_stripe5+0x488/0xdf9 [raid456]
[...]

Der Bug war übrigens reproduzierbar, wenn man versuchte auf einem gerade im Aufbau befindlichen Raid5 einen LUKS-Container anzulegen und darin dann das Filesystem zu erzeugen.

Things you don't want to see when checking a filesystem...

Out of memory: kill process 3641 (xfs_check) score 20034 or a child
Killed process 3642 (xfs_db)
# xfs_check /dev/sda1
Segmentation fault.
*aargh* 1 GB RAM (davon >700MB frei) sollten meiner Meinung nach für ein fsck auf xfs reichen. Und egal wie kaputt das Dateisystem ist, von einem Superblock mit invaliden Daten sollte es keinen Segfault geben.