Marc Richter's Weblog

Archiv für die Kategorie „Linux“

Ich hatte heute den Fall auf der Arbeit, das ich auf eine an einem unserer Suse Linux Server angeschlossene USB 2.0 Festplatte mehrere Gibibyte an Daten kopieren musste.

Das dauerte …. und dauerte …. schliesslich fiel mir auf, das die Daten mit nur 160 KB/s kopiert wurden. Das kam mir komisch vor, schliesslich sollten die Datenraten von USB 2.0 doch deutlich höher liegen. In diesem Wiki-Artikel fand ich schliesslich heraus, das es (laut Spezifikation) 480 Mbit/s hätten sein sollen; also ca. 60 MebiByte pro Sekunde.
Das hat mich dann schon sehr gewundert, schliesslich ist das nur ca. 1/384tel Bruchteil der Transferkapazität des Buses.

Eine erste Recherche heute auf der Arbeit förderte diesen Foreneintrag von Dezember 2007 zu Tage, in dem der Hinweis gegeben wird, das dieses Problem verschwindet, wenn die mount-Option “sync” weggelassen wird. Als ich es ebenfalls probiert habe ohne “sync” zu mounten, war es auch schlagartig schneller.

Inzwischen habe ich etwas genauer nachrecherchiert:
Bei dem ganzen handelt es sich um einen zumindest bei Novell (Suse) bekannten Bug (siehe Novell Bugzilla Database #105871). Ob er nun nur bei Suse Linux auftritt oder ob es ein genereller Linux Bug ist, das weiss ich nicht. Und ehrlich gesagt bin ich jetzt auch zu faul den ganzen Bug zu lesen. Wer mag, kann das gerne nachholen.

Unter’m Strich bleibt zumindest für Suse Linux in der Version 10.x folgende Lösung: USB Laufwerke nicht mit der mountoption “sync” mounten!
(Ob andere Suse Linux Versionen oder gar andere Distributionen betroffen sind weiss ich nicht; einfach ausprobieren!).

Für per “subfs” gemountete Dateisysteme gibt es einen weiterführenden Workarround um sicher zu stellen, das diese Dateisysteme nicht mit “sync” gemounted werden:

1. mkdir -p /usr/share/hal/fdi/policy/95userpolicy
2. Eine Datei namens “nosync.fdi” darin erzeugen (vi /usr/share/hal/fdi/policy/95userpolicy/nosync.fdi) und darin folgenden Inhalt anlegen:
   <?xml version=”1.0″ encoding=”UTF-8″?>
   <deviceinfo version=”0.2″>
   <device>
   <!– disable sync for mount –>
   <match key=”block.is_volume” bool=”true”>
   <match key=”volume.fsusage” string=”filesystem”>
   <match key=”volume.uuid” string=”==UUID==”>
   <merge key=”volume.policy.mount_option.sync”
   type=”bool”>false</merge>
   </match>
   </match>
   </match>
   </device>
   </deviceinfo>
3. Ausführen von “lshal“. Die Passage im unter Punkt 2. aufgeführten Text die hier temporär mit “==UUID==” befüllt ist, mit der Ausgabe dieses Befehls ersetzen.
4. HAL Daemon neu starten (rhal restart)

Ich hoffe dieses hilft einigen von Euch

Wie immer würde ich mich freuen, wenn ihr einen kurzen Kommentar eintragen würdet!

Achja, wie immer der Hinweis: Wer sich über diese “merkwürdigen” Bezeichnungen wie “MebiByte”, GibiByte”, etc. wundert, dem sein mein Artikel über Binärpräfixe als Lektüre ans Herz gelegt

Suchmaschinen bewerten eine Seite und deren Inhalt anhand vieler, teilweise dem normalen User garnicht bewusste, Kriterien um den PageRank einer Seite zu bestimmen, bzw. deren Relevanz zu einem Suchbegriff.
So wird es z.B. von Suchmaschinen inzwischen geahndet, wenn ein und derselbe Inhalt über zwei verschiedene Adressen erreichbar ist.
Es ist für eine Suchmaschine bereits ein Unterschied, ob eine Seite ohne www. Subdomain-Präfix (z.B. http://webseite.de ) oder mit www. Subdomain-Präfix (z.B. http://www.webseite.de ) aufgerufen werden kann. Das ist auch soweit korrekt, da in verschiedenen Subdomains ja vollkommen andere Inhalte bereitgestellt werden können. Im weitesten Sinne können sich ja gar vollkommen andere Server hinter jeder Subdomain verbergen. Und www ist letzten endes auch nur eine Subdomain. Aus Sicht der Bewertungslogik einer Suchmaschine, handelt es sich bei einer Domain http://webseite.de und http://www.webseite.de um völlig verschiedene Webseiten.

Man nehme nur mal an das wäre nicht so. Dann könnte sich ja jeder Kinz und Kunz, der nur ein einziges Mal eine HTML Seite mit allen möglichen Suchbegriffen von Abakus bis Zypern hochgeladen hat, beliebig viele (Sub-/)Domains auf diese HTML Seite zeigen lassen, und somit quasi alleine in den Suchergebnissen auftauchen. Somit verdrängen Website-Spammer ja fast alle anderen relevanten Seiten, die ordnungsgemäß nur eine Domain auf ihre Webpräsenz zeigen lassen, völlig aus den Suchergebnissen.

Man kann dieser Herabstufung der eigenen Präsenz jedoch ganz einfach entgegenwirken: Indem man einfach alle Anfragen an http://webseite.de nach http://www.webseite.de umleitet.
Hierzu bietet sich das Apache Modul mod_rewrite an. Es handelt sich hierbei um ein sehr mächtiges Modul, welches bestimmte Adressen zu beliebigen anderen Adressen umformen kann. Es hat dabei seine ganz eigene Syntax um hierfür Regeln zu definieren. Diese ist viel zu mächtig um sie hier auch nur annähernd zu erklären; wen es interessiert, der kann die Anleitung zu diesem Modul hier finden.
An dieser Stelle sei nur erklärt, wie man seinen Apache Webserver dazu bringen kann, die URL ohne www. zu einer Adresse mit www. umzuformen:

RewriteEngine On
RewriteCond %{HTTP_HOST} ^webseite\.de$ [NC]
RewriteRule ^(.*)$ http://www\.webseite\.de$1 [R=301,L]

Dieser Absatz kann per .htaccess Datei, per vHost oder global in der Apache Konfiguration eingefügt werden. Nicht vergessen den Webserver neu zu starten und ausprobieren!
Ich erkläre die drei Zeilen wie gesagt nur ganz grob, da ich keine Lust habe der 1.000. Wiederkäuer der Moduldokumentation zu werden:

Zeile 1:
Hier wird die Rewrite Engine eigentlich nur aktiviert, damit das Modul überhaupt angesteuert werden kann.

Zeile 2:
Mit “RewriteCond” wird das Muster definiert, welches, sofern es in der eingegebenen Adresse vorkommt, nach den Bedingungen der Direktive “RewriteRule” schliesslich umgeformt werden soll. %{HTTP_HOST} ist eine Variable, die vom Modul mod_rewrite zur Laufzeit der Rewrite Engine automatisch erzeugt wird. Sie beinhaltet die in der HTTP-Protokollanfrage angegebenen Hostnamen.
Dadurch das diese Variable an der 1. Position nach ”RewriteCond” steht, wird dieses bei der Anfrage nach dem an der 2. Position stehendem Muster durchsucht.
Das Muster an der 2. Position nach “RewriteCond” ist ein regulärer Ausdruck; eine weitere Technik, die zu erklären hier den Rahmen sprengen würde. Er besagt, das die Zeichenkette in der Variable %{HTTP_HOST} genau “webseite.de” sein muss; ohne ein Zeichen davor und ohne ein Zeichen dahinter. (“/unterseite.html” zum Beispiel ist nicht Teil dieser Veriablen, da es hinter dem “/” steht). Die Zusatzoption [NC] an der 3. Position nach “RewriteCond” bedeutet, das Groß- und Kleinschreibung in der URL egal ist. (NC = Non Casesensitive).

Zeile 3:
Diese Zeile definiert letzten Endes die Regel, nach der die Anfrage modifiziert werden soll. Es handelt sich zunächst wieder um einen regulären Ausdruck, der besagt, das die gesamte Zeichenkette, welche durch “RewriteCond” analysiert wurde, durch “http://www.webseite.de/urspruengliche/anfrage.html” ersetzt werden soll (“/ursprüngliche/anfrage.html” ist selbstverständlich nur ein Beispiel. Hier wird immer eingefügt, was nach der TLD angegeben worden ist). Dabei soll der HTTP Statuscode 301 (Permanent Redirect) in der Antwort versendet werden und dieses ist die letzte Regel ([L]). Danach sollen keine mehr folgen. So werden Endlosschleifen vermieden und der Arbeitsbereich der RewriteEngine klar abgegrenzt.

Es ist echt unglaublich!
Man sucht stundenlang, und findet NICHTS!

Dann schreibt man irgend eine Mail/ICQ Nachricht, oder einen Blogeintrag und kaum ist das raus: SCHWUPPS – gefunden!
So sollte ich das immer machen …. in diesem Sinne: Wer hat meine 5.000,- € gesehen???

Spass beiseite: Ich habe doch noch in den Tiefen unserer Dateisysteme zwei Archive gefunden.
Eines, mit der Binären Version von fastlogres 0.2.0 für i386er Systeme, und den Quellcode zu fastlogres 0.2.1 .

In letzterem findet sich auch ein sehr ordentlich gepflegtes README, welches Aufschluss auf den Autor gibt. Es handelt sich dabei um einen “Jan Wedekind”. Seine Homepage ist laut README http://www.wede.de und fastlogres soll dort unter http://www.wede.de/sw/fastlogres/ zu finden sein.
Leider ist das nicht der Fall, und die Seite gibt es nicht mehr.
Eine Suche nach “Jan Wedekind” brachte ein paar Blogs hervor, jedoch keine neue Homepage.

Was soll’s? Mach ich halt den Mirror:

Binär:

• fastlogres-0.2.0-i386-linux.tgz

Quelltext:

• fastlogres-0.2.1.tgz

Das ganze steht zum Glück unter GPLv2

20080904 – 22:32 CET
PS:

Dank Sven’s Link (siehe Kommentare) konnte ich die alte Webseite wieder herstellen. … was heisst “wieder herstellen”? – Ich konnte sie herunterladen
Ihr findet die ganze Seite nun hier.

Danke @ Sven!

Und wieder etwas gelernt:

Ich habe versucht ein Source RPM auf einem unserer Server zu installieren. Dieses scheiterte mit folgender Meldung:

error: Installed (but unpackaged) file(s) found:
/usr/BerkeleyDB/3.1/lib/libdb-3.1.la
/usr/BerkeleyDB/3.1/lib/libdb_cxx-3.1.la

RPM build errors:
Installed (but unpackaged) file(s) found:
/usr/BerkeleyDB/3.1/lib/libdb-3.1.la
/usr/BerkeleyDB/3.1/lib/libdb_cxx-3.1.la

Inzwischen habe ich herausgefunden, das dieses ein Sicherheitsmechanismus ist, damit Dateien, die in einem Verzeichnis liegen, in die Dateien gleichen Namens aus dem RPM Paket installiert werden würden, nicht überschrieben werden.
Normalerweise lassen sich bei der Installation eines RPM Paketes Dateien ja zuvor installierten Paketen zuordnen. Installiert man jedoch nun etwas per Hand aus dem Sourcecode, ist es dem RPM System ja nicht möglich, diese Dateien einem Programm zuzuordnen. Daher bricht es lieber ab.

Hat man nun festgestellt, das die angemerkten Dateien überschrieben werden können, fügt man den kompletten Pfad mit den Dateinamen der Programmname.spec – Datei hinzu.
.spec Dateien sind eine Art Bauanleitung, um Sourcecode zu RPM Paketen zu verpacken.
Nachdem die Installation bereits einmal mit der obigen Fehlermeldung fehlgeschlagen ist, befindet sich unter /usr/src/packages/ das entpackte RPM Paket. Unter SPEC steht die .spec Datei, unter BUILD die Sourcen, etc.

Beim obigen Beispiel editieren wir also die Datei /usr/src/packages/SPECS/db3-cxx.spec .
Hier suchen wir nach einem Abschnitt, der %files heisst. Darunter fügen wir die angemeckerten Dateien ein, also:

Vorher:

%files
%defattr(-,root,root)
%{_bindir}/*
%{_libdir}/*.so

Nachher:

%files
%defattr(-,root,root)
%{_bindir}/*
%{_libdir}/*.so
/usr/BerkeleyDB/3.1/lib/libdb-3.1.la
/usr/BerkeleyDB/3.1/lib/libdb_cxx-3.1.la

Nun können wir das ganze nicht einfach erneut über das Source-RPM installieren, da unsere Änderungen sonst direkt wieder überschrieben würden.
Stattdessen wechseln wir in das Verzeichnis /usr/src/packages und führen folgenden Befehl aus:

rpmbuild -ba SPECS/db3-cxx.spec

ACHTUNG:

bei manchen RPM basierenden Distributionen/-versionen gibt es das rpmbuild Programm nicht. Früher wurde der obige Befehl über rpm aufgerufen. Probiert in diesem Fall also:

rpm -ba SPECS/db3-cxx.spec

Hierdurch wird das RPM Binär- und Quellpaket neu gebaut.
Diese Pakete liegen dann in den Unterverzeichnissen SRPMS und RPMS/architektur/ von /usr/src/packages .

Diese können nun Problemlos, wie ein offizielles RPM Paket, installiert werden:

rpm -Uvh /usr/src/packages/RPMS/i586/db3-cxx*.rpm

Sowas habe ich echt noch nicht erlebt:

Auf unserem Server für Webseiten-Statistiken liegt ein Programm namens “fastlogres” im Ordner /usr/bin . Es handelt sich dabei um ein SUSE Linux System. Ein “rpm -qal | grep fastlogres” zeigt mir, das das Programm aus keinem RPM Paket stammt.
Normalerweise legen wir selbst kompilierte Sourcen in einem bestimmten Unterverzeichnis ab, für genau so einen Fall. Jedoch ist das in diesem Fall nicht passiert.

Eine Suchmaschienen-Recherche bringt mir leider keinen Erfolg. In keiner einzigen (!) Suchmaschiene finde ich etwas, das auf dieses Programm hinweist.

Es gibt leider keinen Switch bei dem Programm und keine Manpage, in der eine URL steht. Es gibt lediglich den switch -v zur Ausgabe der Version. Und diese Ausgabe lautet lediglich:

fastlogres 0.2.0

Das Programm löst IPs aus Apache Logfiles zu DNS Namen auf. Dieses tut es deutlich schneller als es der in AWstats eingebaute DNS Resolve Mechanismus tut. Ein Referenzlogfile eines Monats von einer unserer Seiten wird von AWstats in 57 minuten und 39 Sekunden ausgewertet. Dem gegenüber steht fastlogres mit nur 25 minuten und 53 Sekunden; also mehr als doppelt so schnell!

Genau das ist mein Ziel: Diesen Flaschenhals etwas zu “dehnen”.

Bevor ich dieses Programm gefunden habe, bin ich auf “adnslogres”, als Teil der GNU adns Bibliothek aufmerksam geworden. Diese benötigt für dasselbe Logfile

Daher: Bis jetzt ist fastlogres mit abstand das schnellste Programm!

Nur finde ich es nirgendwo im Netz
Es kann doch nicht sein, das auf unserem Server ein Programm läuft und derart super funktioniert, ohne das man im Internet auch nur einen Hinweis darauf findet.

Wenn jemand dieses Tool kennt, wäre ich höchst dankbar, wenn er mir hier einen Hinweis geben könnte.

Auch Alternativen, die die beschriebene Aufgabe erfüllen können, sind sehr gerne gesehen!

Hallo zusammen!

Ich habe ja länger nichts geschrieben. Aufgrund der heutigen Aktion mit VMware unter Linux sehe ich mich dazu aber fast gezwungen. Das ist mal wieder _so_ schwachsinnig und typisch VMware, das muss einfach festgehalten werden:

Was ich schon kenne im Zusammenhand mit VMware Server unter Linux ans laufen bringen ist, das man irgendwie immer erst einen Kernel kompilieren muss, da die mit der Distribution mitgelieferte GCC Version in aller Regel eine andere ist, als die, mit der der ebenfalls mitgelieferte Kernel kompiliert wurde.

Zumindest war das unter meinem Debian System so.
Nun habe ich jedoch ein (k)ubuntu auf meinem Laptop und bekomme nach der Installation von VMware Server, beim starten der VMware Konsole diesen Block an Fehlermeldungen:

/usr/local/lib/vmware/bin/vmware:
/usr/local/lib/vmware/lib/libgcc_s.so.1/libgcc_s.so.1: version `GCC_3.4′ not found (required by /usr/lib/libcairo.so.2)
/usr/local/lib/vmware/lib/libgcc_s.so.1/libgcc_s.so.1: version `GCC_4.2.0′ not found (required by /usr/local/lib/libstdc++.so.6)
/usr/local/lib/vmware/lib/libgcc_s.so.1/libgcc_s.so.1: version `GCC_3.4′ not found (required by /usr/lib/libcairo.so.2)
/usr/local/lib/vmware/lib/libgcc_s.so.1/libgcc_s.so.1: version `GCC_4.2.0′ not found (required by /usr/local/lib/libstdc++.so.6)
/usr/local/lib/vmware/lib/libgcc_s.so.1/libgcc_s.so.1: version `GCC_3.4′ not found (required by /usr/lib/libcairo.so.2)
/usr/local/lib/vmware/lib/libgcc_s.so.1/libgcc_s.so.1: version `GCC_4.2.0′ not found (required by /usr/lib/libstdc++.so.6)

Ich denke mir schon so .oO( … oh NO! Nicht schon wieder Kernel backen! ). Ist aber auch garnicht nötig gewesen!

Auf dieser Seite fand ich die Lösung. Sie liest sich erstmal so “… alles klar … lösche ich mal ein paar Libraries … dadurch wird’s bestimmt besser …”</ironie>. Aber: Das klappt wirklich!

Man muss nur die Datei lib/libgcc_s.so.1/libgcc_s.so.1 (im Unterverzeichnis, wo man den VMware Server installiert hat. Bei mir z.B.: /usr/local/lib/vmware/lib/libgcc_s.so.1/libgcc_s.so.1 ) entfernen, bzw. umbenennen. Anschliessend startet VMware ohne Probleme … kurios!

Mal wieder: Wir brauchen mod_auth_mysql , haben den apache2.2.8 auf dem Server laufen, und kriegen diesen tollen Fehler:

# /server/service/www/apache2/bin/apxs -c -L/usr/lib/mysql -I/usr/include/mysql -lmysqlclient -lm -lz mod_auth_mysql.c
/server/service/www/apache2/build/libtool –silent –mode=compile gcc -prefer-pic -DLINUX=2 -D_REENTRANT -D_GNU_SOURCE -g -O2 -pthread -I/server/service/www/apache2/include -I/server/service/www/apache2/include -I/server/service/www/apache2/include -I/usr/include/mysql -c -o mod_auth_mysql.lo mod_auth_mysql.c && touch mod_auth_mysql.slo
mod_auth_mysql.c:591: error: expected expression before ‘mysql_auth_config_rec’
mod_auth_mysql.c:591: warning: cast to pointer from integer of different size
mod_auth_mysql.c:591: error: initializer element is not constant
mod_auth_mysql.c:591: error: (near initialization for ‘mysql_auth_cmds[0].cmd_data’)
mod_auth_mysql.c:595: error: expected expression before ‘mysql_auth_config_rec’
mod_auth_mysql.c:595: warning: cast to pointer from integer of different size
mod_auth_mysql.c:595: error: initializer element is not constant
mod_auth_mysql.c:595: error: (near initialization for ‘mysql_auth_cmds[1].cmd_data’)
mod_auth_mysql.c:599: error: expected expression before ‘mysql_auth_config_rec’
mod_auth_mysql.c:599: warning: cast to pointer from integer of different size
mod_auth_mysql.c:599: error: initializer element is not constant
mod_auth_mysql.c:599: error: (near initialization for ‘mysql_auth_cmds[2].cmd_data’)
mod_auth_mysql.c:603: error: expected expression before ‘mysql_auth_config_rec’
mod_auth_mysql.c:603: warning: cast to pointer from integer of different size
mod_auth_mysql.c:603: error: initializer element is not constant
mod_auth_mysql.c:603: error: (near initialization for ‘mysql_auth_cmds[3].cmd_data’)
mod_auth_mysql.c:607: error: expected expression before ‘mysql_auth_config_rec’
mod_auth_mysql.c:607: warning: cast to pointer from integer of different size
mod_auth_mysql.c:607: error: initializer element is not constant
mod_auth_mysql.c:607: error: (near initialization for ‘mysql_auth_cmds[4].cmd_data’)
mod_auth_mysql.c:611: error: expected expression before ‘mysql_auth_config_rec’
mod_auth_mysql.c:611: warning: cast to pointer from integer of different size
mod_auth_mysql.c:611: error: initializer element is not constant
mod_auth_mysql.c:611: error: (near initialization for ‘mysql_auth_cmds[5].cmd_data’)
mod_auth_mysql.c:615: error: expected expression before ‘mysql_auth_config_rec’
mod_auth_mysql.c:615: warning: cast to pointer from integer of different size
mod_auth_mysql.c:615: error: initializer element is not constant
mod_auth_mysql.c:615: error: (near initialization for ‘mysql_auth_cmds[6].cmd_data’)
mod_auth_mysql.c:619: error: expected expression before ‘mysql_auth_config_rec’
mod_auth_mysql.c:619: warning: cast to pointer from integer of different size
mod_auth_mysql.c:619: error: initializer element is not constant
mod_auth_mysql.c:619: error: (near initialization for ‘mysql_auth_cmds[7].cmd_data’)
mod_auth_mysql.c:623: error: expected expression before ‘mysql_auth_config_rec’
mod_auth_mysql.c:623: warning: cast to pointer from integer of different size
mod_auth_mysql.c:623: error: initializer element is not constant
mod_auth_mysql.c:623: error: (near initialization for ‘mysql_auth_cmds[8].cmd_data’)
mod_auth_mysql.c:627: error: expected expression before ‘mysql_auth_config_rec’
mod_auth_mysql.c:627: warning: cast to pointer from integer of different size
mod_auth_mysql.c:627: error: initializer element is not constant
mod_auth_mysql.c:627: error: (near initialization for ‘mysql_auth_cmds[9].cmd_data’)
mod_auth_mysql.c:631: error: expected expression before ‘mysql_auth_config_rec’
mod_auth_mysql.c:631: warning: cast to pointer from integer of different size
mod_auth_mysql.c:631: error: initializer element is not constant
mod_auth_mysql.c:631: error: (near initialization for ‘mysql_auth_cmds[10].cmd_data’)
mod_auth_mysql.c:635: error: expected expression before ‘mysql_auth_config_rec’
mod_auth_mysql.c:635: warning: cast to pointer from integer of different size
mod_auth_mysql.c:635: error: initializer element is not constant
mod_auth_mysql.c:635: error: (near initialization for ‘mysql_auth_cmds[11].cmd_data’)
mod_auth_mysql.c:639: error: expected expression before ‘mysql_auth_config_rec’
mod_auth_mysql.c:639: warning: cast to pointer from integer of different size
mod_auth_mysql.c:639: error: initializer element is not constant
mod_auth_mysql.c:639: error: (near initialization for ‘mysql_auth_cmds[12].cmd_data’)
mod_auth_mysql.c:643: error: expected expression before ‘mysql_auth_config_rec’
mod_auth_mysql.c:643: warning: cast to pointer from integer of different size
mod_auth_mysql.c:643: error: initializer element is not constant
mod_auth_mysql.c:643: error: (near initialization for ‘mysql_auth_cmds[13].cmd_data’)
mod_auth_mysql.c:651: error: expected expression before ‘mysql_auth_config_rec’
mod_auth_mysql.c:651: warning: cast to pointer from integer of different size
mod_auth_mysql.c:651: error: initializer element is not constant
mod_auth_mysql.c:651: error: (near initialization for ‘mysql_auth_cmds[14].cmd_data’)
mod_auth_mysql.c:655: error: expected expression before ‘mysql_auth_config_rec’
mod_auth_mysql.c:655: warning: cast to pointer from integer of different size
mod_auth_mysql.c:655: error: initializer element is not constant
mod_auth_mysql.c:655: error: (near initialization for ‘mysql_auth_cmds[15].cmd_data’)
mod_auth_mysql.c:659: error: expected expression before ‘mysql_auth_config_rec’
mod_auth_mysql.c:659: warning: cast to pointer from integer of different size
mod_auth_mysql.c:659: error: initializer element is not constant
mod_auth_mysql.c:659: error: (near initialization for ‘mysql_auth_cmds[16].cmd_data’)
mod_auth_mysql.c:663: error: expected expression before ‘mysql_auth_config_rec’
mod_auth_mysql.c:663: warning: cast to pointer from integer of different size
mod_auth_mysql.c:663: error: initializer element is not constant
mod_auth_mysql.c:663: error: (near initialization for ‘mysql_auth_cmds[17].cmd_data’)
mod_auth_mysql.c:667: error: expected expression before ‘mysql_auth_config_rec’
mod_auth_mysql.c:667: warning: cast to pointer from integer of different size
mod_auth_mysql.c:667: error: initializer element is not constant
mod_auth_mysql.c:667: error: (near initialization for ‘mysql_auth_cmds[18].cmd_data’)
mod_auth_mysql.c:671: error: expected expression before ‘mysql_auth_config_rec’
mod_auth_mysql.c:671: warning: cast to pointer from integer of different size
mod_auth_mysql.c:671: error: initializer element is not constant
mod_auth_mysql.c:671: error: (near initialization for ‘mysql_auth_cmds[19].cmd_data’)
mod_auth_mysql.c: In function ‘format_request’:
mod_auth_mysql.c:947: warning: pointer/integer type mismatch in conditional expression
apxs:Error: Command failed with rc=65536

Woran liegt’s? Zunächst: Keine Ahnung.

Irgendwann findet man aber raus, das man diesen Patch anwenden muss. Dann geht’s problemlos.

Das geht wie folgt:

1. Am besten das mod_auth_mysql – Quellenverzeichnis nochmal löschen und das TAR neu entpacken.
2. Wechsel in das Quellenverzeichnis mod_auth_mysql-3.0.0.
3. Ausführen von “patch < ../mod_auth_mysql-3.0.0-apache-2.2.patch” (ich gehe davon aus, das der Patch ein Verzeichnis höher liegt; sonst bitte entsprechend anpassen).

Das sollte es gewesen sein. Als Resultat bekommt man:

patching file mod_auth_mysql.c

Anschließend sollte sich das Modul wie beschrieben per apxs kompilieren lassen.

Heute wurde eine Meldung auf Heise.de veröffentlicht, das WordPress in Version 2.5.1 erschienen ist.

Es soll eine “schwerwiegende Sicherheitslücke” behoben worden sein. Details zu dem Problem werden noch nicht genannt, sollen aber “bald” veröffentlicht werden. Zudem soll die Version 2.5.1 70 weitere Verbesserungen mit sich bringen. Unter anderem auch eine Performacesteigerung im Backend.

Ich habe einen Fehler beim Upgrade gemacht. Dieser scheint jedoch ohne weitere Folgen geblieben zu sein:

Ich habe auf meinem System für jede WordPress Version ein eigenes Verzeichnis (wordpress_2.5, wordpress_2.3.3, etc.). Das eigentliche “Live-Blog” wird dann aus einem Symlink “wordpress” auf die jeweils aktuelle Version bedient.

Das mache ich so, damit, falls ein Update mal nicht so läuft wie geplant, ich schnell wieder zurück switchen kann.

Das Updatearchiv auf Version 2.5.1 heisst “latest.tar.gz”. Entpackt man es ohne weitere Optionen, landen alle Dateien im Verzeichniss wordpress.

Regulär lege ich ein neues Verzeichniss an, wordpress_2.5.1 in diesem Fall, und entpacke es dann mit “tar xfz latest.tar.gz -C wordpress_2.5.1″. Dieses mal habe ich das allerdings versäumt und durch den Symlink “wordpress->wordpress_2.5″, die Dateien der Version 2.5 überschrieben.

Zum Glück muss man zum einen die Konfigurationsdatei von wp-config-sample.php in wp-config.php umbenennen, wodurch man diese durch so eine Aktion nicht versehentlich überschreiben kann. Zum zweiten kommen alle User-Uploads wie Bilder, Sounds usw. (sog. “Assets”) in einen Unterordner, wp-content/uploads . Dieser ist im neuen Release leer und unter Unix werden beim entpacken von Archiven mit tar standardmäßig Ordnerinhalte in einen bestehenden Ordner übernommen, statt diesen Ordner zu überschreiben.

Somit scheint alles fehlerfrei abgelaufen zu sein und die HP erstrahlt nun in Version 2.5.1

Eine Änderung sehe ich direkt: Eingebettete Bilder werden nun offenbar mit einem weissen Rahmen umrahmt.

Naja – mir geht’s in erster Linie um die Security Issues

Neeeee – was ärgert mich sowas:

Ich bin seit 2 Stunden dran um einen Fehler bei der mod_auth_mysql Authentifikation des Apache2 Webservers zu finden, und die einzige Webresource in der ich fündig werde (nach 2 Stunden, wohlgemerkt) ist ein italienisches Privatblog.

Ich hatte das Problem, das nach der Umstellung nur noch folgender Fehler in Logfile geschrieben wurde:

(9)Bad file descriptor: Could not open password file: (null)

Mich hatte es zwar schon stutzig gemacht, das da etwas von einer Passwort Datei stand, aber kapiert habe ich es soweit erstmal nicht, da ich nicht wusste ob die MySQL Tabelle evtl. aus Sicht des Servers tatsächlich eine Art “Passwortdatei” ist.

Auf jeden Fall lag es letzten endes daran, das Apache2 authz_user standardmäßig aktiviert, was der Apache1 nicht tut. Also erwartet er auch die Übergabe einer Passwortdatei. Diese war nicht definiert, also spuckt er die obige Fehlermeldung aus.

Behoben werden kann es ganz einfach, indem in der Apache2 Server-Config (httpd.conf, .htaccess, etc.) die folgende Einstellung gesetzt wird:

AuthBasicAuthoritative Off

Das war’s!

(01.09.2008)
PS:

Nach der oben beschriebenen Methode kann man sich zwar wieder über niedriger priorisierte Authentifikationsmodule wie z.B. mod_auth_mysql anmelden, es erscheint im error-log jedoch nach wie vor die Meldung

(9)Bad file descriptor: Could not open * file: (null)

Dieses kann man beheben, indem man zusätzlich zu “AuthBasicAuthoritative Off” die folgenden zwei Einstellungen setzt:

AuthUserFile /dev/null
AuthGroupFile /dev/null

War mir irgendwie erst heute aufgefallen, das das nach wie vor geschrieben wird … ~:)

Habe ich mich immer gefragt, aber nie herausgefunden: Wie entfernt man eine leere Zeile mit grep?

Geht ganz einfach:

grep -v '^$'