Samstag, 12. Dezember 2009
RAID ist gut für Server!!!
wir hatten gestern einen interessanten Ausfall eines Kundensystems, den ich Euch nicht vorenthalten will. Rechner crashed, hat Schwierigkeiten mit seinem RAID-Controller, Hr. Kollege B. schraubt den Rechner auf und rennt dann relativ fassungslos mit dem Fund durchs Büro - und deshalb haben wir natürlich auch Photos davon gemacht:
Das Ding auf dem Bild ist der Cache-Speicher des Controllers, mit Batterie-Backup drauf (damit er einen write-cache machen kann, der auch beim Stromausfall die Daten noch hält). Von der Idee gut, aber irgendwas hat die Ladelogik mit dem Lithium-Polymer-Akku darauf gemacht, was dieser nicht mochte.
Anders als NiCd-Akkus (die schweigend sterben oder explodieren) haben LiPo-Akkus die Eigenschaft, bei Überladung Gase zu erzeugen, und sich aufzublähen. Viel Überladung = viel Gas = viel Druck.
Der Akku hat sich so aufgeblasen, dass er die ganze Platine verbogen hat...
(Ohne Akku ging der Speicher wieder, wenn natürlich dann auch nicht mehr "battery-backuped", und nach ein paarmal hin und her bauen war er dann allerdings auch ganz kaputt).
Dienstag, 24. November 2009
Die Killer-Applikation für IPv6 gefunden
Sonntag, 22. November 2009
The Linux Programming Interface
es gibt ein neues Buch. Über Linux. Und Programmierschnittstellen. The Linux Programming Interface.
Naja, eigentlich gibt es das Buch noch nicht, aber es sieht so aus, als ob es das Buch jetzt irgendwann dann doch endlich gibt, und zwar schon in der ersten Hälfte 2010...
Warum mich das interessiert?
... weil ich dafür 2003 und 2004 ein paar Kapitel Korrektur gelesen habe (das übliche Zeug: serielle Schnittstellen, tty allgemein, Prozesse und Prozess-Gruppen, utmp/wtmp und ähnlich stinkende Ecken von Unix). Eigentlich sollte das Buch dann auch relativ bald erscheinen, aber dann ist der Autor (Michael Kerrisk) vergoogled worden -- sprich: arbeiten bei Google, Google ist ganz toll, jeder arbeitet freiwillig 60 Stunden in der Woche -- und das Buchprojekt ist halbwegs in der Versenkung verschwunden
Seit einem halben Jahr ist er wieder ent-googled - und hat das Buchprojekt wieder aufgenommen. Hier geht's zum Blog dazu.
Ich verdien' daran nix (bekomme aber eine Danksagung und hoffentlich ein Belegexemplar ) - glaube aber, dass das ein wirklich nützliches Buch für alle Leute wird, die unter Unix oder Linux systemnah programmieren wollen oder müssen. Schaut's Euch im Blog an, da sind auch Inhaltsangaben der einzelnen Kapitel - aktuell ist Kapitel 60, wie programmiere ich einen UDP/TCP-Socket-Server?
Mittwoch, 20. Mai 2009
Trau keiner Statistik...
das will ich Euch nicht vorenthalten, aus dem Kapitel "wie macht man geeignete Umfrage-Ergebnisse? man fragt halt passend!"...
Zum Thema "92% der Deutschen wollen ganz dringend Internetsperren", oder auch eben nicht, wenn man nur geeignet fragt - hier der Artikel in der Zeit.
gert
Mittwoch, 8. April 2009
SCO Unix, VMware und das Computermuseum
machmal macht man ja Dinge, die nicht 100% rational erklärbar sind, aber man kann dann doch nicht aus seiner Haut, und so.
Wie der eine oder andere weiss, ist mein Arbeitsplatzrechner zu Hause ("das Ding mit Maus, Tastatur und Bildschirm dran") ein SCO Unix, genauer gesagt, ein SCO Open Server 3.0.
Installiert im März 1993(!). Ja, wirklich. Eine Betriebssystem-Installation, die seit über 16 Jahren stabil und ohne reinstall ausgekommen ist (und das ist gut, weil die Original-Boot-Diskette vermutlich nicht mehr lesbar ist, und ob mein aktueller Streamer die Original-Install-Bänder noch lesen kann, weiss ich auch nicht).
Natürlich ist die Hardware nicht ganz so alt - 1993 war das ein "echter" 386er mit 40 MHz und 16 Mbyte RAM, wurde dann mal zu einem 486 aufgerüstet (Asus SP3, das erste PCI-Mainboard auf dem Markt, signifikante Fehler in eigentlich jedem Chip auf dem Board) und später zu einem Pentium-200 (Tyan Tomcat-Board). Nach zwei Mainboard-Ausfällen aufgrund eines defekten Netzteils (grrr) ist inzwischen ein AMD K6-450 drin, mit gigantischen 384 Mbyte DRAM.
Die Platte wuchs von etwa 500 Mbyte (Fujitsu SCSI, 3.5" volle Bauhöhe, an einem Adaptec 1542B ISA-SCSI-Controller) zu meinem Traum: gespiegelte 2x 9Gbyte Ultra2-SCSI IBM an einem ICP/GDT Cache-RAID-Controller, PCI natürlich.
Die Graphikkarte entwickelte sich von einer Tseng ET4000 über eine MIRO S8 (die erste PCI-Graphikkarte auf dem Markt, S3 805 mit diskret aufgebauter PCI-Logik - volle Baulänge! - liegt hier im Museum noch rum) über eine Miro 20SV (S3 968) - wohlgemerkt: alle noch mit Original-SCO-Treibern! - zu einer Matrox MGA G450 mit einem selbst nach SCO portierten XFree86 3.3.6 (inklusive Kernel-Patch für mmap()-Unterstützung von PCI-Memory). Allerdings ohne Dual-Head, das geht erst ab XFree86 4.x und das war mir dann doch zu heftig.
Aktuelle Software ist auf dem System leider aus verschiedenen Gründen kaum noch zum Laufen zu bringen:
- kein Thread-Support im System
- keine unix sockets
- kein IPv6
- "kein Linux" (und ja, für heutige Software-Autoren ist das ein echtes Hindernis)
... weshalb ich seit Jahren den Firefox von Neko's Linux-Rechner per Remote-X11 verwende - tut prima, hat aber das Problem, dass der Rechner (AMD Athlon 900) auch gerade ausgemustert wird, und nachdem Neko inzwischen total verMACt ist, geht das damit nicht mehr.
Also: neuer Rechner, aktuelle Hardware (auf der das SCO nicht mehr booten würde, wegen "was ist das für ein Prozessor? was ist das für ein Bus? was ist das für eine Netzwerkkarte? *PANIK*"), Dual-Head-Graphikkarte, und so.
Aber gleichzeitig soll das venerable SCO natürlich weiterlaufen - und noch einen Rechner, der dauernd an ist, und Strom frisst, braucht's hier wirklich nicht.
Die Idee
Mit meinem Spielwindows habe ich es erfolgreich praktiziert, warum soll das nicht auch mit SCO gehen? Einfach virtualisieren. VMware workstation oder VMware server, "tut einfach".
Googeln gegangen: ja, es gibt Erfahrungsberichte, dass das geht (hier, hier oder insbes. hier). Dass es zwar mit Schmerzen verbunden ist (SCSI-Controller, Treiber, ...), aber es haben Leute erfolgreich hingekriegt. Allerdings nur mit OSR 5.0.<aktuell>, nicht mit 3.0 - welches wirklich ein paar Generationen älter ist.
Interessantes Tidbit am Rande: einer der SCO-Entwickler, mit dem ich früher viel zu tun hatte (Bela Lubkin), ist jetzt bei VMware und damit natürlich die Adresse für knifflige Fragen in diesem Zusammenhang. Bela hat sogar noch einen Account auf dem Rechner, um den es geht
Der Plan
Hier steht grad eh' ein Superduper-Server für einen Kunden, der da einen Teil seiner Altlasten (einen Windows-Server und ein SCO OpenServer 5.0.5) virtualisieren will. Xeon-Dual-Core, 2G RAM, schnelle Platten, damit macht das doch Spass
Unix-Platten "einfach so" in VMware-Disk-Images verwandeln geht nicht. Also:
- in einer VM ein SCO 5.0.x installieren, Install-Medien liegen hier eh noch rum
- in dieser VM eine zusätzliche Festplatte einbinden, etwas grösser als auf dem alten System
- via "dd" das System blockweise rüberkopieren (über Netz vom laufenden System in die VM/disk1)
- die zusätzliche Festplatte als primäre Platte einer neuen VM einbinden
- booten, freuen, Treiber für Netzwerk, X11, usw. fixen
Die Umsetzung, und die lustigen Probleme
Tja, wenn das mal alles so einfach wäre.
Der erste Teil ("SCO OSR 5.0.x installieren") hat verblüffend gut geklappt. Die Boot-Disketten waren alle noch lesbar, die Installation hat funktioniert, und meinen "free for private use"-License-Key aus der Zeit, wo SCO noch an "Leute verwenden unser Produkt!" interessiert war habe ich auch gefunden.
Netzwerk & die Einbindung der neuen Platte waren auch einfach, Fingerübung.
Die alte Platte mit "dd" kopieren war schon aufregender. Eigentlich war der Plan gut, aber ich vergass ein Detail: SCO ODT 3 hat keinerlei Support für Files grösser 2 Gbyte.
Das heisst:
# dd if=/dev/hd00 bs=512k | rsh neu dd of=/dev/hd10 bs=512k
hat zwar prima funktioniert, aber nur 2G von 9G kopiert, dann Abbruch mit Fehler.
Die wichtigen Sachen waren aber dabei (Partitionstabelle, Boot-Sektor, Root-Filesystem). Den Rest hab' ich dann halt Filesystem für Filesystem kopiert (SCO! es gibt Unix-Partitionen, und in diesen drin dann "divvy"-Slices, und da drin sind dann die Filesysteme) - statt einer Platte bzw. zwei Partitionen waren halt dann etwa 10 "dd...rsh..."-Aktionen nötig. Etwas nerviger als nötig, aber immer noch viel weniger Arbeit als "Partitionen und Filesystem von Hand anlegen und dann 10000e von kleinen Files per rsync kopieren" (was auf dem Zielrechner auch erstmal gar nicht drauf war, usw.)
So, dann also mal sehen...
... neue VM gebaut, besagte Platte als "primär" eingebaut, gebootet...
crash boom, Kernel Panic zu Besuch - klar, er findet sein Root-Filesystem nicht.
SCO Unix ist ein altes System, von dem die anderen gelernt und 10 Jahre verbessert haben - sprich: so nette Automatismen wie heute unter Linux "finde einfach die erste Platte im System und binde sie ein, und dann schau mal, wie weit Du kommst - und zur Not sagt man root=/dev/hda17 am Boot-Prompt" gab's halt nicht, die Zuordnung Devices<->Controller ist fest in den Kernel kompiliert.
Das war mir eigentlich klar, ich wollte auch nur sehen, ob's überhaupt zumindest den Kernel lädt - was es getan hat, also frisch ans Werk...
... die Device-Treiber und die Boot-Festplatte
Die grundlegende Vorgehensweise war ganz klassisch, wie man das auch im Zweifel bei einem echten Problemrechner machen würde - nicht-bootende Festplatte in einen anderen Rechner einbauen, dort den Kernel fixen, dann wieder zurückbauen und testen. Bei VMware geht das natürlich einfacher, weil man einfach abwechselnd die SCO 5 und SCO 3 VM hochfahren kann.
In der SCO 5 VM (wo die SCO 3-Platte als "disk 1" dranhängt) kommt man dann mit
# mount /dev/i1.root /mnt
# chroot /mnt /bin/sh
# cd /etc/conf/cf.d
# <kernelconfig verfummeln>
# ./link_unix
# exit
# umount /mnt
# init 0
ziemlich schnell zu einem neuen Kernel. War natürlich trotzdem nicht so einfach, denn SCO 3 hat ab Werk keinen Treiber für den emulierten BusLogic PCI-SCSI-Controller, und der Treiber für SCO 5 (den da oben alle referenzieren) tut nicht, denn die interne PCI-Bus-Logik hat sich zwischen SCO 3 und SCO 5 dann doch geändert - es linkt nicht, mit einer klaren "hier geht's nicht weiter" Fehlermeldung:
undefined first referenced
symbol in file
pci_readbyte /etc/conf/pack.d/blc/Driver.o
pci_finddevice /etc/conf/pack.d/blc/Driver.o
pci_readword /etc/conf/pack.d/blc/Driver.o
... und das klang erstmal nicht gut. Also weitergesucht, und tatsächlich ein Treiberpaket für SCO 3.0 und BusLogic-Controller gefunden (auf der Mylex-Webseite, die BusLogic irgendwann mal gekauft haben). Das Paket bestand natürlich aus einem DOS-.exe, was dann eine Unix-BTLD-Diskette erstellt... gah. Aber mit einer Windows-XP VM, Samba und einem Floppy-Image in VMware ging das dann auch.
Installation in der SCO 3 chroot-Umgebung ("btldinstall /mnt", wohin vorher /dev/rfd0138ds18 gemounted war, in /etc/conf/cf.d/mscsi den Treiber für die erste Festplatte auf "blc" umstellen) hat auch geklappt, Kernel hat sich auch linken lassen, aber beim Booten trotzdem crash boom, kein SCSI-Controller gefunden.
Auf dem Weg noch ein paar kleinere Probleme gefunden:
- In der SCO 5.0-VM hatte ich "snapshots" aktiviert, damit sind die Änderungen an der SCO 3.0-Platte nicht auf die Platte geschrieben worden, und die neuen Kernel sind gar nicht erst angekommen (lösbar, snapshots abschalten)
- Aus irgendwelchen widrigen Gründen war die "SCSI"-Festplatte für die SCO 3.0-VM im VMware kein SCSI mehr, sondern IDE (lösbar, im .vmdk-File von controller="ide" auf controller="buslogic" umstellen - mit einer Linux-Boot-CD verifiziert: jetzt SCSI!)
Ging aber alles trotzdem nicht. Resümee: der SCO 3.0 blc-Treiber spielt nicht mit VMware-Buslogic-Controllern. (Bin grad noch dran, das Thema mit Bela zu diskutieren, weil "jetzt wollen wir's wissen" ).
Mmmh, was nun. IDE disks?
Bei einer Neuinstallation ist das kein (grosses) Problem, nachdem IDE ja "wd1003" kompatibel sind, und dieser Controller alt genug ist, dass SCO ihn wirklich unterstützt (mein erstes SCO wurde noch auf einer echten MFM-Platte an einem WD1006 installiert). Schwierig ist die Umstellung.
Einen anderen SCSI-Treiber zu verwenden ist ganz einfach - den neuen Treiber installieren (legt einen Haufen Zeug in /etc/conf/{pack.d,sdevice.d,...} ab), in /etc/conf/cf.d/mscsi die Zuordnung Platte<->Treiber anpassen, neuen Kernel bauen, rebooten, gut ist.
Das Problem mit dem IDE-Support ist aber, dass der bei SCO nicht als "SCSI"-Treiber läuft, und sich mit den normalen Bordmitteln für "mach mir einen neuen Controller / eine neue Platte" (mkdev hd) nicht um eine IDE-Platte erweitern lässt - das System sagt "wenn ich jetzt ein SCSI-System bin, wäre ich beim nächsten Booten ein IDE-System (Reihenfolge im System), und deshalb supporte ich diesen Prozess nicht".
Egal. Grosser Hammer, und nachher die Scherben richten
In /etc/conf/cf.d/mscsi erstmal dem SCSI-Subsystem alle Geräte weggenommen, und in /etc/conf/sdevice.d/$treiber die ganzen SCSI-Treiber abgeschaltet. Dann in /etc/conf/sdevice.d/wd den generischen WD-Treiber aktiviert (erste Spalte auf "Y"), festgestellt, es reicht nicht, und die "Instanzen 0 und 1" (.../sdevice.d/wd0 und .../wd1) auch aktiviert. Das ist bei SCO 5 anders, da gibt es nur einen Treiber "wd", der sich um alle Controller und die Platten kümmert.
Also, neuen Kernel als Boot-Kernel abgelegt, SCO 5 VM runtergefahren, die Platte wieder auf controller="ide" umgestellt (jetzt soll sie ja eine IDE-Platte sein), frohgemut die SCO 3 VM gebootet, und... bah... crash boom. Die Disk-Geometrie gefällt ihm nicht, und der SCO 3 "wd"-Treiber kann auch keine Platten grösser als 8 Gbyte - wir haben hier 9...
Jetzt war's aber einfach, denn der "proof of concept" ist erbracht. Also zwei IDE-VM-Disks mit jeweils 5G angelegt, die zwei Unix-Partitionen mit ihren ganzen Filesystemen von der 9G-Platte rüber-dd-t (also genauer: die Partitionen angelegt, die Filesysteme in "exakt gleich gross" angelegt, dann die Filesysteme dd't - es ist einfach schneller als rsync).
... und siehe da...
... es tut!!!
... Netzwerk?
Im alten System war im Lauf der Zeit so diverses drin - erstmal gar kein Netzwerk (1993? Ich bitte Euch, das war teuer! Und ich hatte auch nur einen Rechner...), dann eine günstig erstandene WD8013 aus einer Insolvenz (100 Mark für 2 Stück haben die damals gekostet, glaube ich - dafür war es eine 16-Bit-ISA-Karte mit BNC und 10BaseT und AUI!!), später dann mal eine DEC 21143-basierte 100Mbit-Karte (memory-leak im Kernel, ganz schlecht) und jetzt ist da so was billig-Realtek-basiertes drin, was 100Mbit spricht, einen SCO 3-Treiber mitbringt, und einfach funktioniert.
VMware bietet zwei verschiedene emulierte Netzwerkkarten an: eine AMD LANCE und eine Intel E1000 (1G). Und eine "pseudovirtualisierte", die natürlich einen Vmware-Treiber braucht (den es für Randgruppen-Betriebssysteme nicht gibt). Die 1G-Karte hat sicher auch keine Treiber für ein Betriebssystem aus der Zeit von 10 Mbit - also AMD. Oder aufgeben.
Erster Versuch: SCO's eigenes "netconfig" befragt. Nein, nichts, was auch nur annäherend nach AMD Lance aussieht.
Bei Intel geguckt, wegen e1000-Treiber - gibt's zwar für SCO, aber nur für SCO 5, was eine andere Netzwerkarchitektur als SCO 3 hat. Damit wird's nichts.
Also wieder Freund Google bemüht. Verschiedene erfolglose Treffer, aber bei einem Hersteller von AMD Lance-basierten Ethernetkarten tatsächlich fündig geworden - ein Treiberbundle, wo das zwar nicht draufstand, aber tatsächlich ein Treiber für SCO 5 und für SCO 3 drin war. Juhuu!
Die Installationsanleitung war auch, äh, interessant - ein Tarball, den man erstmal auspacken soll, und dann mit dem SCO-Tar (der ein wenig anders ist...) via tar cnv6 * auf (virtuelle) Diskette, dann mit custom installieren. Tja, wenn das mal so straightforward gewesen wäre - denn das SCO 3 hatte ja noch kein Netz, und das SCO 5 hat einen "tar", der Informationen über die directories mit speichert. Was den "tar" von SCO 3 zur Verzweiflung gebracht hat - weil er beim Auspacken den Directory-Eintrag von tmp/ gefunden hat, ein File namens tmp angelegt hat, und dann beim Auspacken des nächsten Files (tmp/perms/pnt.pre oder so) über das File namens tmp gestolpert ist...
Das hab' ich aber dann irgendwann hingebracht (unter SCO 3 mit "gtar" ausgepackt und mit dem
System-"tar" wieder eingepackt, dann waren nur noch Einträge für die Files da, nicht mehr für die Directory-Struktur).
SCO 3 wollte aber trotzdem nicht, weil custom auf /dev/install zugreift, was ein "autosense floppy device" ist, welches sich mit der virtuellen Floppy von VMware beisst. Nächster Versuch: custom -m /dev/fd0135ds18 - das ist wenigstens nicht mehr mit "tar: checksum error" gestorben, aber installiert hat es auch nicht - irgendein File hat gefehlt.
Eigentlich aber egal. So ein Installmedium besteht nur aus einem Tarball mit genau der Ziel-Verzeichnis-Struktur und ein paar Files in /tmp (Permissions, Pre-Install-Script, ...) - das kann man auch einfach von Hand draufballern.
Gesagt, getan, netconfig aufgerufen, pnt-Treiber ausgewählt (andere IP-Adresse konfiguriert, natürlich), und siehe da...
... es netzt (das sind die Bootmeldungen mit der erkannten Hardware, die Zeile mit %pnt und Ethernet ist die spannende).
X11?
Was jetzt nicht geht, ist X11. Das pack' ich evtl. noch an, wenn ich mal viel Zeit habe, aber es wird hochgradig knifflig...
... denn:
- VGA spezifiziert als Auflösungen nur 640x480 mit 16 Farben (kann XFree gar nicht) oder 320x200 mit 256 Farben (das funktioniert sogar, ist aber hinreichend sinnlos)
- wenn man aus einer "VGA"-Karte mehr rausholen will, muss man wissen, was das für ein Chipsatz ist und wie man da die Auflösungen umstellt
- VMware emuliert eine "generische" VGA-Karte, d.h. der XServer findet keinen "bekannten" Chipsatz
- XOrg in "aktuell" verwendet in diesem Fall einen VESA-Bios-Aufruf zur Umstellung der Auflösung und danach den generischen VGA-Treiber fürs Pixel-Schubsen - das tut, ist auch (dafür) ausreichend performant, aber...
- ... das kann "mein" XFree86 3.3.6 natürlich noch nicht, ich müsste also noch ein aktuelles XOrg portieren, und das setzt im Zweifelsfall Kernel-Infrastruktur voraus (fürs Vesa-Bios), die einfach nicht da ist.
Also wenn mal jemand langweilig ist, und er ganz dringend graue Haare braucht, schick' ich ihm meine VM...
(SCO 5 kann es übrigens, das bringt einen Vesa-VGA-Treiber mit - das ist zwar mit der emulierten Busmaus vom VMware nicht wirklich 100% glücklich, aber für die Dinge, wo man wirklich X11 braucht, reicht's)
Resumee
Sinnlos war's schon, aber es hat grossen Spass gemacht. Alte Unixe bringen manchmal eine Befriedigung, die so ein Vollkasko-Linux einfach nicht bringt - da tut's einfach "ab Werk" (im Zweifel), oder es haben schon 100 andere das Problem gehabt und Googlen bringt sofort die Lösung...
Dienstag, 31. März 2009
Windows XP und IPv6, manuell konfiguriert
> netsh interface ipv6 install
OK.
> netsh interface ipv6 show int
...
(aha, es heisst "LAN-Verbindung")
> netsh interface ipv6 add address LAN-Verbindung 2001:608:8003::dead
OK.
(huch? einfach so? Windows, ohne Widerspruch??)
Also noch ein paar Routen:
> netsh interface ipv6 add route 2001:608:8003::/64 LAN-Verbindung
> netsh interface ipv6 add route 0::0/0 LAN-Verbindung 2001:608:8003::1
... *geht*.
Sagenhaft
Hintergrund des Problems: $hier im Netz gibt's IPv6, aber es wird nicht autoconft, weil hier ein paar Vista-Rechner sind, auf denen Java-Entwickler entwicklern. Und solange die nicht ausdruecklich "wir brauchen das jetzt, $Kunde fragt" zu dem Thema sagen, zieh ich mir den Schuh "Du hast IPv6 angemacht und seitdem geht mein Netz nicht mehr!!" nicht an. Ich will aber natuerlich auch auf meinem Spiel-und-Test-XP IPv6, also statisch... mein NetBSD macht das schon lang und problemlos.
Mittwoch, 11. März 2009
Computer und Telefax = lustige Probleme
die letzten paar Wochen habe ich für einen Kunden ein ausgesprochen interessantes Problem gejagt.
Vom Standort A aus (Endkunde) waren 3 verschiedene Faxgeräte nicht per Modem erreichbar. 100% Fehlerrate. Beliebig oft reproduzierbar. Egal, mit welchem Modemtyp (Elsa, USR, Blatzheim). Abbruch immer an der selben Stelle: Verbindungsaufbau klappt, aber beim Training am Anfang der eigentlichen Seitenübertragung kommt vom Empfänger keine Rückmeldung mehr, irgendwann gibt das sendende Modem auf.
Natürlich erstmal auf das Faxgerät beim Empfänger geschoben, und/oder die Telefonanlage im Haus. Aber: mit einem Papierfax an der selben TK-Anlage geht es, zu den selben Empfängern. Schon mal sehr sonderbar.
Beobachtung: alle 3 Empfänger verwenden exakt das selbe Gerät, lt. NSF-Frames "etwas von AVM", also irgendso eine Fax-Server-Grütze wohl.
Nun gut. Von München aus getestet. Selbes Phänomen: reproduzierbar, es geht nicht.
Von zu Hause getestet (anderer Modemtyp). Mit meinem Wunderzyxel (2864DI) geht's! Hurrah, eine Lösung gefunden, ein 2864 zum Endkunden geschickt.
... ging natürlich da auch nicht (und hat lustige und aufregende Crashes der Modem-Firmware produziert, aber das ist ein anderes Thema).
Verschiedes ausgetestet, irgendwann ratlos den Blatzheim-Support involviert "haben Sie eine Ahnung, warum das nicht geht?" - die Blatzheims hatte ich an verschiedenen Standorten getestet, mit verschiedenen Firmware-Versionen: reproduzierbares "geht nicht".
Blatzheim-Support mailt zurück "von uns aus geht's, hier ist das Logfile". Wah!
... und darüber bin ich auch dann drauf gekommen:
- Der Kunde schickt "+49(0)40/123456" als Fax-Absenderkennung mit
- mein Kunde schickt "+49(0)89/54321" als Absenderkennung mit
- der Blatzheim-Support schickt "0228 12345" mit
- mein Modem zu Hause schickt "+49-89-35655025" mit
... und genau das war's: wenn man dem AVM-Drecksding ein Fax mit einer Absenderkennung mit Klammern oder '/' drin schickt, hängt es sich komplett weg und beantwortet die entsprechenden Frames nicht mehr. Absenderkennung normalisiert, schon kann ich vom Endkunden aus mit 100% Erfolg wieder an die drei betroffenen Empfänger faxen.
Das ist doch krank, oder? Was ist aus dem guten "be liberal in what you accept" geworden?
(Und nein, T.30 erlaubt mir, diese Zeichen zu senden - wir tun das seit 12 Jahren oder so, und es gab bisher kein Problem, was sich damit in einen Zusammenhang bringen gelassen hätte)
Sonntag, 22. Februar 2009
127.0.0.1
Unixe werden echt seltsam, wenn man ihnen die 127.0.0.1 wegnimmt... :-o
Bei der "planlosi.de braucht SSL"-Aktion gestern musste ich neue IP-Aliases konfigurieren, und das ist bei Solaris alles ein wenig "anders" - und irgendwie hab' ich mich vertippt, auf jeden Fall war auf lo0 nicht mehr 127.0.0.1, sondern jetzt 0.0.0.6.
... was erstmal "scheinbar" nicht mehr gestört hat...
... aber vorhin kam dann Neko und meinte "mit meiner Mailzustellung klappt was nicht".
Geguckt, sehe Mail durchlaufen, Testmail von Space geschrieben (Space - Solaris-Kiste - SMTP weiter) - tut auch alles. Versucht, lokal eine Mail zu schreiben - hängt. Hmmm, komisch.
"ls -l | sendmail -v ..." -> connecting to 127.0.0.1 ... hängt. Sehr komisch.
Wüst alles mögliche verdächtigt, zumal da auch noch ca. 40 Procmail-Prozesse von Neko rumhingen (die auf spamc/spamd gewartet haben). Mailer angehalten, spamd angehalten, versucht spamd neu zu starten -> "bind() to 127.0.0.1:nnn failed"
Aus irgendeinem Grund dachte ich mir, schauste mal "ifconfig lo0" an, und siehe da, kein 127.0.0.1 mehr da... - was die ganzen obskuren Probleme erklärt: wenn er versucht, "localhost"-Connections über den Default-Gateway zu erreichen (der das natürlich wegwirft, statt es zu routen), dann hängt das halt alles bzw. timeouted...
Und dabei ist noch gar nicht Montag!
Freitag, 20. Februar 2009
IPv6 und SSL suckt...
also die Kombination aus "IPv6 und SSL und Apache" suckt irgendwie... man muss alles doppelt eintragen, weil man den SSL-Vhost natürlich nicht mit "*:443" definieren kann (sofern man mehr als einen SSL-Vhost laufen hat), und dann wird die Konfiguration lang und unhandlich... und wenn man dann evtl. auch noch SSL und nicht-SSL will (oder zumindest für nicht-SSL einen redirect, statt einer Fehlermeldung) ist es endgültig vorbei
Listen 195.30.8.32:80
Listen [2001:608:0:1007::32]:80
Listen 195.30.8.32:443
Listen [2001:608:0:1007::32]:443
<VirtualHost *:80>
ServerName planlosi.de
...
</VirtualHost>
<VirtualHost 195.30.8.32:443>
ServerName planlosi.de:443
SSLEngine on
SSLCertificateFile ...
...
</VirtualHost>
<VirtualHost [2001:608:0:1007::32]:443>
# und nochmal das ganze Gesums, wenn man nicht dafür jetzt ein Include definiert
</VirtualHost>
... aber jetzt hat planlosi.de auch SSL, was für "wir sind unterwegs und wollen was bloggen" schon irgendwie netter ist als "einfach so über plain HTTP authentisieren".
gert,
für ein IPv6-only Internet "rettet die Apache-Configs!"
Dienstag, 10. Februar 2009
Redundanz und Load-Sharing, anschaulich erklärt
in bester Tradition von Dyfas Loadbanana habe ich hier ein schönes Bild zur Erklärung "was ist eigentlich Load-Sharing" bzw. "was ist ein redundantes Setup, was beim Ausfall einer Komponente noch funktioniert"
Spricht eigentlich für sich, oder?
(Quelle: Sheraton-Hotel in Riad, Saudi-Arabien - sehr nettes Hotel übrigens ).
Samstag, 7. Februar 2009
Strom am Flughafen!
in den letzten Jahren galt es an den Flughäfen ja als "schick", dass man die Dinge des täglichen Lebens nicht sieht - insbesondere "keine offen sichtbaren Steckdosen".
Als Viel-Laptop-Herumflieger hat man irgendwann einen gewissen Blick dafür, wo wohl die Steckdose für die Putzteams (Bodenwischmaschinen, Staubsauger, ...) sein wird, aber die sind dann oft weit von der nächsten Sitzgelegenheit entfernt, also auch unpraktisch.
Um so größer die Überraschung gestern am Münchner Flughafen, Terminal 2 - ein deutliches Hinweisschild an der Wand "Here be Powa!"
... gefreut, suchen gegangen...
... weiter gesucht...
... aus dem Fussboden kommendes Kabel gefunden, was im Kabelschacht verschwindet...
... komisch, hier muß doch irgendwo...
Oh ja, tatsächlich. Gut versteckt, und nur zu finden, wenn man wirklich danach sucht (und dabei vermutlich ein recht sonderbares Bild abgibt...). Aber so positioniert, daß man von den Sitzen - zumindest von denen relativ nah am Fenster - gut drankommt. Wunder dieser Welt!
Samstag, 24. Januar 2009
2.0
Nachdem ich den Umzug von Nekos Blog auf den neuen Rechner machen durfte, habe ich auf einem eigenen Schreibzugang bestanden!