Software

Thema: Wie erzeugt man mittels eines Perl-CGIs ein PDF, welches schöner aussieht als die bisherige "Wir drucken eine Webseite aus und stopfen das in einen Briefumschlag, den wir dann manuell beschriften müssen."-Lösung?

CPAN ist ja meistens die Rettung. Leider nur nicht heute. Es gibt zwar einige Module, die PDF lesen, auseinandernehmen und auch erzeugen können, allerdings ist die Dokumentation meist recht spärlich oder das Modul so mächtig, das ich nicht gerafft habe, wie ich anfangen muss, geschweige denn einen Briefkopf nach CI und DIN in endlicher Denkzeit erzeugen kann.

Lösung: PDFLaTeX. Recht schnell fand sich eine Vorlage des IMTEK der Uni Freiburg, die auf KOMA basierte und sich einfach anpassen lies.

Mein CGI erzeugt jetzt also eine temporäre TeX-Datei (File::Temp ist gut zu haben, nur sollte man "CLEANUP=>1" nicht vergessen), jagt diese zweimal durch pdflatex (wegen der Seitenzahlen), gibt dann "Content-Type: application/pdf" aus und wirft das erzeugte PDF hinterher, der Browser wird schon Das Richtige^TM daraus machen.

Passt. Und ist gar nicht einmal so unperformant, wie die Lösung erst zu sein schien.

In meiner Zeit als Server-Admin habe ich einige Programme/Systeme zum Erfassen von Statistiken vieler Server hinter mir, aber die meisten waren recht krude oder so dilettantisch geschrieben, dass ich es auch gleich selbst hätte Programmieren können.

Oder sie waren einfach zu kompliziert (wie z.B. mein angedachter Versuch, eigene MIBs für SNMP zu schreiben, um damit z.B. Statistiken von SpamAssassin via Cacti erfassen zu können. Zur Erhaltung meiner geistigen Gesundheit habe ich das aber aufgegeben.) oder aber überhaupt nicht zu erweitern.

Und dann gab es wiederum welche, die zwar für 5 Server noch recht gut ausgesehen haben, aber die bei näherer Betrachtung nicht skalierten.

Schlussendlich bin ich dann bei Munin gelandet, welches eine recht durchdachte Struktur mit Plugins für die eigentlichen Funktionen bietet, auf RRDTool aufsetzt und somit automagisch gute Grafiken erzeugt und auch gleichzeitig die Daten in einem für diesen Bereich de-facto Standard hält.

Am besten gefällt mir dabei, dass ich die Plugins in jeder beliebigen Sprache schreiben kann (sogar als Shell-Script), solange ich die Werte in einem bestimmten Format auf STDOUT ausgebe. Dies macht es sehr einfach, mal eben schnell für einen interessanten Werte Statistiken erzeugen zu lassen. Und das Beste dabei ist: Ich werfe mein Plugin einfach in ein entsprechendes Verzeichnis auf dem jeweiligen Server, starte den Munin-Node neu und bin fertig. Der pollende zentrale Server wird die neuen Werte fortan automatisch berücksichtigen und in der jeweiligen Übersichtsseite darstellen.

Und da ich mittlerweile auch bereits einige Plugins geschrieben habe, werde ich wohl einmal Das Richtige^TM tun und den Code beim Munin-Exchange einwerfen, damit andere auch profitieren können.

Liebes Lazyweb,
ich habe einen einfachen Wunsch. Ich möchte unter Gnome mit metacity als Windowmanager für ein spezielles Fenster/Programm alle Key-Bindings (wie ALT+F1, etc.) abschalten, so dass diese direkt an die Applikation durchgereicht werden.

devilspie ist zwar ein netter Ansatz, aber kann das, was ich brauche (derzeit noch) nicht.

Was ist also zu tun?

Mit Grüßen,
dein Sven

Eigentlich propagiere ich ja normalerweise, dass sich ein in der Entwicklung befindliches System (hier Debian Etch) nicht auf produktiven Servern zu befinden hat.

Normalerweise stimmt das ja auch. Und normalerweise kommt man mit der stabilen Version auch weit genug.

Aber irgendwann kommt in der heutigen schnelllebigen Zeit dann doch der Moment, wo man neue Features von neuen Versionen braucht, z.B. das libc6-xen-Paket für den /lib/tls-Support mit nosegneg in Dom0 und DomU.

Oder man will OTRS2 einsetzen, ohne apache2.2 und Perl5.8.7 selbst zurück portieren zu müssen. Oder man will einen korrekt als Paket vorliegenden Jabber-Server haben.

Und damit schlage ich die Kurve zu meinem Server hier: Seit kurzem ist dort auch Debian Etch installiert, was erst einmal meine Webseiten zerwürfelte, denn der Apache2.2 liefert per default die Seiten mit UTF-8-Deklaration aus, während der Inhalt doch noch klassisches 8bittiges ISO-8859-15 ist. Aber das war einfach zu beheben. Mittlerweile durch umkodieren der Seiten nach UTF8.

Dümmer war dagegen folgende Meldung vom pyicq-Transport für meinen Jabber-Server:

[...]
   File \"/usr/share/jabber-pyicq/src/sasl.py\", line 124, in _init_
       SASLConnectAuthenticator._init_(self, componentjid)
   TypeError: _init_() takes exactly 1 argument (2 given)

Suchend und kramend in diversen Foren und Listen kam ich zu dem Ergebnis: Läuft nicht mehr und der Autor ist derzeit untergetaucht. Leider sind die anderen verfügbaren ICQ-Transports noch älter als der vorliegende, funktionieren nur mit bzw. innerhalb jabberd-1.4 oder sind sonstwie disfunktional.

Mit ejabberd brauche ich den SASL-Kram nicht für den Interconnect zwischen Jabber-Server und Transport und da die aktuelle Version des jabberd-2.0 eh nur noch PostgreSQL unterstützt, war der Entschluss schnell gefasst: jabberd-2.0 runter, ejabberd-1.1.2 drauf.

Und da bin ich nun. Eigentlich sollte sich nichts geändert haben, außer das ich jetzt wesentlich näher am Standard bin und auch gleichzeitig eine Vorlage für ein anderes Jabber-Projekt habe.

Ich konvertiere gerade Datenbank und Webserver nach UTF8. Bisher mit eher mäßigem Erfolg, aber das wird schon noch.

Auf jedenfall ist es daher nicht ratsam, derzeit Komemntare o.ä. abzusetzen, da ich die Datenbank öfters gnadenlos mit einem älteren Stand überschreiben werde.

Nachtrag: Nachdem sich heraus gestellt hat, dass die Datenbank-Inhalte bereits UTF8 waren, nur die Tabellen selbst von MySQL noch als 8bit geführt worden sind, war doch alles einfacher, als zuerst befürchtet.

Zuerst habe ich die Tabellen mit ein paar ALTER TABLE Statements auf Cordermann gebracht, dann in Serendipity die Kodierung auf UTF8 umgestellt. Schlussendlich war noch ein Umstellen der Option "Datenbank-Zeichensatzkonvertierung aktivieren" von Nein auf Ja nötig und alles ist wieder ein Butter.

Die vorherigen defekten Einträge belasse ich aber so, da zu diesem Zeitpunkt das Problem ja noch existierte.

Der nächste in der Runde ist Performancing/ScribeFire, ein als Firefox-Addon implementierter Blog-Editor.

Er integriert sich direkt und für den Anfang etwas ungewöhnlich als Top/Bottom-Bar in den Browser, ist aber ebenfalls angenehm zu bedienen, bietet ebenfalls WYSIWYG-, Source sowie Preview-Ansicht.

Wie mir bisher dämmert, ist das größte Problem die Vielfalt der XMLRPC-Schnittstellen und die korrekte Implementierung des Gegenstückes.

Daher werde ich auch bei diesem Editor wieder warten müssen, bis ich den Eintrag zur veröffentlichen versucht habe, bevor ich sehe, ob ich weitersuchen muss.

Nachtrag: Dieser Editor hat keine Probleme mit dem Veröffentlichen, allerdings existiert auch hier das Problem mit UTF-8 vs. 8bit. Evtl. findet sich ja ein Serendipity-Plugin, welches den Zeichensatz wieder gerade biegt.

Flock baut auf Firefox auf und nennt sich selbst ganz unbescheiden "the social web browser".

In der aktuellen Version (leider noch nicht in Debian enthalten) ist ein Bug behoben, der vormals die Benutzung mit Serendipity unmöglich machte.

Soweit fühlt sich das Ding auch ganz nett an, aber das war bei Bleezer ja auch nicht anders, bis dieser dann beim Veröffentlichen eines Eintrages patzte.

Die Funktion ältere Einträge via XMLRPC zu laden und zu editieren habe ich bisher leider noch nicht finden können, aber das ist keine hohe Priorität, wäre aber nett zu haben.

Nachtrag: Auch Flock hat Probleme beim Veröffentlichen. Zuerst einmal, und das fällt zuerst auf, gibt es keine Möglichkeit, in etwas anderem als UTF-8 zu posten, meine Webseite ist aus "hysterischen" Gründen aber noch in 8bit abgefasst (und das wird sich so schnell auch nicht ändern). Dann bekommt man auf der konsole eine Fehlermeldung

[Exception... "Component returned failure code: 0x80004003 (NS_ERROR_INVALID_POINTER) [nsIRDFService.GetLiteral]"  nsresult: "0x80004003 (NS_ERROR_INVALID_POINTER)"  location: "JS frame :: file:///home/oweh/bin/flock-dir/components/flockBlogWebServiceMovabletype.js :: anonymous :: line 184"  data: no]

vorgesetzt und via Fenster mitgeteilt, dass die Veröffentlichung fehlgeschlagen ist. Leidre ist das nicht der Fall, denn der fragliche Eintrag wird gleich drei-fach veröffentlicht, so dass man manuell aufräumen muss.

Tja, schade, denn die Software machte keinen schlechten Eindruck.

Der WYSIWYG-Editor von Serendipity ist zwar recht nett, aber irgendwie wird die JavaScript-erweiterte Textarea immer langsamer, teilweise sogar so langsam, das beim normalen Tippen Buchstabendreher auftreten und die CPU meines Rechners jeden Buchstaben mit einem Sprung auf 100% begrüßt (wobei das auch an Firefox liegen kann).

Also wird es Zeit, das deaktivierte XMLRPC-Interface wieder anzuwerfen und mal ein paar standalone Blog-Editoren unter Linux zu testen.

Dieser Artikel z.B. wird mit Bleezer, einem Java-basierten Editor geschrieben, der bisher einen recht guten Eindruck macht.

Nachtrag: Leider gibt es eine Fehlermeldung, wenn man den Artikel publishen will, dieser erscheint aber dennoch auf der Webseite. Ob das an Bleezer oder an Serendipity liegt, wird sich zeigen müssen, je nachdem, wie die anderen Editoren, die es so gibt, sich schlagen.

Wer noch andere Editoren kennt, die frei (wie in Sprache) [oder nötigenfalls auch "frei" wie in "Bier"] sind und unterLinux lauffähig sind: immer her damit.

Nein, das wird kein HowTo, wie man einen Server innerhalb weniger Minuten fix und fertig aufgesetzt bekommt, sondern lediglich ein Dank an Steve Kemp, der mir und meinen Kollegen durch das Schreiben der xen-tools das Erstellen von neuen Xen-Domänen unendlich einfacher gemacht hat.

Thanks Steve!

Was bisher geschah: VIA-SATA ist Schrott, mit Promise hat's funktioniert.

Wie es weiter ging: Das RAID1 ist mittlerweile aufgebaut, die Daten ge'rsynct, mittels GRML wurde dann auch der Rest übertragen, GRUB installiert und alles bereit gemacht.

Nun die alten Platten abhängen, das BIOS auf "Booten von PCI-Gerät" einstellen, einschalten und ... ein langes Gesicht machen.

Das mdadm aus Debian Sid erzeugt mittlerweile einen Superblock im Format 1.0 (wenn /etc/mdadm/mdadm.conf entsprechend eingestellt ist, was derzeit default ist), der Kernel erkennt aber nur solche mit Format 0.90 korrekt und automatisch.

Natürlich könnte ich jetzt eine initrd anlegen, aber ich traue diesem ganzen Early-Userspace-Kram nicht so recht über den Weg.

Mir blieb also nichts anderes übrig, als mein fertig synchronisiertes RAID1 wieder aufzubrechen, eine Platte davon mit korrektem Superblock im degraded mode als neues RAID1 anzuwerfen und die Daten noch einmal durch die Gegend zu schaufeln.

Wenigstens habe ich so einmal etwas Belastung auf den Platten erzeugt und jeder Block wurde mindestens einmal angefasst, so dass ich Hoffnung haben kann, dass die Platten nicht gleich Dead-on-Arrival sind.

Gegeben sei ein Rechner mit Yukon2-Netzadapter (mit sky2 v1.5 unter Linux 2.6.18.2) und die Notwendigkeit, hier VLANs hinzuzufügen und auch wieder zu entfernen.

Das Hinzufügen einen VLANs (entweder via /etc/network/interfaces) oder auch manuell mittels vconfig funktioniert ohne Probleme, das zusätzliche Interface ist verfügbar und benutzbar.

Interessant wird es, wenn man ein VLAN wieder entfernen will, dann funktionieren andere VLANs auf dem gleichen Master-Interface nicht mehr.

Beispiel:

eth0 (Master, keine IP)
eth0.4 (192.168.100.4)
eth0.1023 (192.168.120.1)
eth0.1965 (192.168.140.20)

Jetzt füge ich mittels "vconfig add eth0 42" ein weiteres VLAN hinzu:

eth0 (Master, keine IP)
eth0.4 (192.168.100.4)
eth0.1023 (192.168.120.1)
eth0.1965 (192.168.140.20)
eth0.42

Soweit keine Probleme. Wenn ich jetzt aber mittels "vconfig rem eth0.42" dieses Interfaces entferne, so sind alle anderen VLAN-Interfaces an eth0 auch tot, nur das ungetaggte eth0 funktioniert noch.

Wobei sich "tot" nur darin äußert, dass keine Pakete mehr rein oder raus laufen, die Interfaces bleiben UP und sind vorhanden.

Auch der aktuelle 2.6.19-rc5 mit sky2 v1.10 zeigt das gleiche Verhalten, andere Treiber, z.B der skge oder auch e100/e1000 etc. sind nicht betroffen.

Der für mich interessante Teil besteht jetzt darin, den Leuten auf der netdev-Liste dieses Phänomen zu erklären, damit das Problem jemand finden und fixen kann.

Heute bin ich endlich dazu gekommen, ein sehr merkwürdiges Problem mit mysql-server-5.0 von backports.org auf einem Debian Sarge AMD64-System zu untersuchen.

So startete der mysqld ab und zu beim Booten nicht, sondern das Init-Scripte gab nur aus, in /var/lib/mysql wäre zu wenig Platz, was aber kompletter Unsinn ist, denn diese Ausgabe erfolgt nur, wenn weniger als 4MB frei sind, während auf dem fraglichen System über 300GB verfügbar waren.

Der Fehlschlag beim Start trat aber nicht immer auf, in nicht vorhersehbaren Intervallen war der Start möglich oder er schlug fehl.

Nach näherer Betrachtung stellte sich dann das folgende Verhalten von df heraus:

root@xen-16:~# while sleep 1; do BLOCK_SIZE= df --portability /; done
Filesystem Size Used Avail Use% Mounted on
/dev/sda1 1.8MiB 175KiB 1.5MiB 11% /
Filesystem 1024-blocks Used Available Capacity Mounted on
/dev/sda1 1829159K 178307K 1553259K 11% /
Filesystem Size Used Avail Use% Mounted on
/dev/sda1 1.8 178 1.6 11% /
Filesystem 1024-blocks Used Available Capacity Mounted on
/dev/sda1 1829159M 178307M 1553259M 11% /
Filesystem Size Used Avail Use% Mounted on
/dev/sda1 1.8M 178k 1.5M 11% /
Filesystem 1024-blocks Used Available Capacity Mounted on
/dev/sda1 1829159 178307 1553259 11% /
Filesystem Size Used Avail Use% Mounted on
/dev/sda1 1.9MB 179kB 1.6MB 11% /

Man beachte hierbei die sich verändernde Darstellung bei aber immer gleichem Aufruf von df.

Dieses Verhalten, das nur auf AMD64 und auch nur dann auftritt, wenn BLOCK_SIZE= gesetzt (eigentlich gelöscht) wird, hat größeres Stirnrunzeln verursacht.

Die Versionen der coreutils in Debian Etch und Sid zeigen diese Verhalten nicht (mehr).

Diesre Eintrag berichtete von meinen Erfahrungen bei der Migration eines größeren Webservers mit Benutzer-Homepages von einer alten Sun E150 auf eine neue Dual-DualCore Opteron-Maschine.

Leider stürzte Firefox ab, bevor ich den Eintrag fertigstellen konnte. Daher gibt es jetzt nur die kurze Fassung.

Das es nicht einfach ist, einen Webserver zu bauen, der mit potentiell "feindlichen" Scripten und Programmen beladen werden wird (lies: Webserver für Studenten und Mitarbeiter), war mir ja schon von Anfang an bewusst.

Aber die Arbeit, die ich bisher investieren musste, zeigt mir doch, wie unausgegohren dieses Feld immer noch ist. Auch die verfügbare Doku ist eher dünn gesäht und auf objektive Vergleiche, was wann wo wozu warum womit wogegen nutzbar ist, findet man nur selten.

Ich bin daher Marc für seine Dokumentation mehr als dankbar, weil er mir zumindest die Arbeit abgenommen hat, die verbreitesten Lösungen zu suchen, zu sammeln und zu bewerten.

Marc berichtete ja schon von seinen Versuchen, allerdings ist seine Problemstellung etwas anders als meine, so dass ich glücklicherweise zu einem anderen Ergebnis kommen konnte.

Mir reicht daher suExec für alle normalen CGI-Scripte (Shell, Perl, Ruby, Python, ELF, ...) und suPHP für den Rest, da ich die User nur über mod_userdir verwalten muss und keine einzelnen Kunden oder virtuellen Domänen voneinander trennen muss.

Glücklicherweise, denn ein eigenes PHP für jeden User (über 1500) oder andere manuelle Verrenkungen wären nicht lustig gewesen. Das System soll so einfach wie möglich bleiben, damit auch ein uneingeweihterer Admin damit klar kommt, ohne auf Dinge wie veränderte Init-Scripte, erweiterte Apache-Komponenten oder manuell gepatchte Wrapper "hereinzufallen" (was zwangsläufig passiert, egal wie gut die intenre Dokumentation dazu ist).

Bitte, bitte, $DEITY, lass den Schmerz vergehen.

Warum werde ich gleichzeitig mit

1. einem uralten und halbkaputten Solaris 2.6
2. 35GB zu tranferierneden Daten auf einer Sun Enterprise 150
3. Cisco IOS 12.3(T)
4. Kernel 2.6.17
5. und den daraus resultierenden bekannten "Interessantheiten" im Bezug auf Window Scaling

geschlagen?

Es macht wirklich keine Freude, wenn man mit 50KB/s diese Datenmengen transferieren muss und einem dabei immer wieder der Transfer-Prozess auf der Datenquelle "abhanden" kommt.