Nur eine Datenbank zurücksichern:

sed -n '/^-- Current Database: `dbname`/,/^-- Current Database: `/p' dumpfile > dbname.sql 2>error

Nur eine Tabelle zurücksichern:

sed -n -e '/CREATE TABLE.*mytable/,/CREATE TABLE/p' mysql.dump > mytable.dump

Hat man mehrere Tabellen, die ähnlich heißen sollte man Backquotes für die Namen verwenden.

 
Danke an uloBasEI von stackoverflow.com und Prabhat Kumar von adminlinux.blogspot.com für diese Tipps.

Hartnäckig halten sich allerdings zahlreiche Gerüchte über PHP, von schlechter Performace (sehr häufig) über Bedenken wegen fehlender Objektorientierung bis zur Angst, dass Zend aufgrund seiner Vormachtstellung im Development von PHP die Sprache vollständig kontrolliert. Manuel Lemos hat dazu auf phpclasses.org einen sehr guten Artikel verfasst, den sich jeder Interessierte mal zu Gemüte führen sollte. Sogar als erfahrener Developer kann man dort noch das ein oder andere, das man vielleicht noch nicht wusste, erfahren. Oder wussten Sie, dass man mit PHP Windows-Dienste erstellen kann?

Can't connect to X11 window server using ':1.0' as the value of the DISPLAY variable.

Nach etwas googeln hat mir dann stress_junkie vom Forum linuxquestions.org die Erklärung (inklusive Lösung) geliefert:

If the Java program is running under your own account then the problem comes from DISPLAY being incorrectly defined. Try this:

export DISPLAY=”:0.0″

If a different user account is running the program then the user account that “owns” the console must add permission for others to display on “their” X display. Try this:

xhost +local:all

If the program is being used on a different computer, say 192.168.3.5 then try this:
Code:

xhost +inet:192.168.3.5

Ich wollte die GUI nämlich über einen anderen User laufen lassen. Nachdem ich bei diesem den Befehl xhost +local:all ausgeführt hatte, konnte ich zurück zum ausführenden User wechseln und das Programm problemlos starten. Denn nun hatte es die Berechtigung, das X11 window des xterm-Besitzers benutzen zu dürfen.

Stuart Herbert hat sich dankenswerter Weise schon vorher die Mühe gemacht, die 5 gängigsten Varianten (suphp, mpm-peruser, mpm-itk, PHP + FastCGI und suexec + PHP + FastCGI) einem Vergleich zu unterziehen. Zwar sind die durchgeführten Performance-Tests mit Vorsicht zu genießen (sie spiegeln in keiner Weise ein realitätsnahes Szenario wieder und übersteigern die Performanceverluste erheblich), aber die Artikel vermitteln dennoch ein sehr gutes Bild der jeweiligen Verfahren und ihrer Stärken und Schwächen.

Ich habe mich für meinen Server schlussendlich für mpm-itk entschieden, da es sehr flexibel ist, alle Vorteile von mod_php weiterhin genutzt werden können und der zusätzliche Speicher- und CPU-Bedarf nicht ganz so extrem ist wie bei mpm-peruser. Zudem setzt die Sicherung im Gegensatz zu den fcgi-Varianten hier bereits im Apachen – also an der richtigen Stelle – an. Die Performance-Einbußen sind, anders als der Test es vermuten lassen würde, im Praxisbetrieb sehr moderat.

Um Apache2 mit ITK-MPM einzurichten bedarf es – vorausgesetzt Apache2 ist bereits installiert – unter Ubuntu/Debian nur eines kurzen Befehls:

apt-get install apache2-mpm-itk

Ein vermutlich vorhandenes anderes MPM (Multi-Processing Module) (standardmäßig dürfte das apache2-mpm-prefork sein) wird bei der Installation automatisch entfernt. Es kann also immer nur ein MPM gleichzeitig tätig sein, was ja auch logisch ist.

Nach dem automatisch durchgeführten Apache-Neustart ist das Modul sofort einsatzbereit. Um Gebrauch davon zu machen fügt man in den VirtualHost-Eintrag folgendes ein:

<VirtualHost *:80>
  ServerName www.example.com
  ...
 
  <IfModule mpm_itk_module>
    AssignUserId username groupname
    MaxClientsVHost 50
    NiceValue 10
  </IfModule>
</VirtualHost>

Alle Angaben sind optional. Wird kein Username zugewiesen läuft die jeweilige Domain unter dem Standard-User und der Standard-Gruppe (normalerweise www-data). Der MaxClients-Eintrag ermöglicht es (wie der Name schon sagt), die maximale Anzahl Clients für diesen spezifischen VHost festzulegen. Mit dem nice-Parameter kann man schlussendlich die Prozesspriorität pro VHost regeln (negative Werte = Priorität niedriger als normal).

Update: Es ist wichtig, jedem vHost auch wirklich eine User-Id zuzuordnen. Anderenfalls wird die Id von Apache genommen, was idR dann root ist (“Note that if you do not assign a user ID, the default one from Apache will be used.” lautet der lapidare Hinweis auf der Projektwebsite).

Zuletzt trat so eine Situation auf, als ich von Joomla 1.5.22 auf das ausgereiftere 1.6.3 wechseln wollte. Schon vorher wurde ich mehrmals vom Admin-Team auf einen Wechsel angesprochen, allerdings halte ich bei Joomla Versionen kleiner als x.x.3 generell für relativ unsicher. Die Liste der Security-Fixes im Patchlog von 1.6.1 und 1.6.2 hat mich dann auch wieder in dieser Ansicht bestätigt. Mit dem Release von 1.6.3 kam dann die Entscheidung, jetzt zu wechseln. Dazu mussten etliche Komponenten, u.a. das Premiumsystem, und das Template umgeschrieben werden. Weitere Komponenten wie das Kunena-Forum mussten aktualisiert und wieder dem vorherigen Funktionsstand angepasst werden.

Die größte Änderung betraf jedoch Huruhelpdesk, für das es keine J!1.6-kompatible Version gibt. Zudem scheint der Entwickler James R. Erickson momentan ziemlich inaktiv zu sein. Daher habe ich beschlossen, den Huruhelpdesk 0.88d – den wir bei rising-gods.de als Ticket-System einsetzen – selbst 1.6-kompatibel zu machen. Alles in Allem kein besonders schwieriges Unterfangen, wenn auch zeitaufwändig, da die Joomla-Docs für 1.6 zurzeit noch einfach miserabel sind. Besonders das Herausfinden der neuen XML-Strukturen für die Installations-XMLs hat viel länger gedauert, als eigentlich nötig. Letztendlich jedoch war auch dieses Hindernis genommen und nach einer Woche Regelbetrieb in der 150k-Community von Rising Gods ohne Zwischenfälle habe ich mein Projekt auf Github veröffentlicht, um auch anderen Huru-Nutzern den Umstieg auf Joomla 1.6 zu ermöglichen.

Um nun das 5800 doch noch in mein Richtfunk-WLAN-Prohjekt einbinden zu können benutze ich die (zurzeit noch kostenlos erhältliche) Software Tivi. Die hat – im Gegensatz zu den 4 oder 5 anderen Alternativen, die ich ausprobiert habe – den Vorteil, dass sie sich mit jedem SIP-Provider, also auch dem der Fritzbox, verbinden kann. Nimbuzz, Fring & Co. funktionieren nur mit echten Internet-SIP-Anbietern wie 1&1, voip-sip.de oder Sipgate.

Zunächst muss ein Registrierschlüssel für die Software erzeugt werden. Den gibt es momentan noch kostenlos bei tivi.com nach Eingabe der IMEI (nötig, damit tivi.com die App signieren kann). Die IMEI findet man bei allen Symbian-Handies übrigens via *#06# heraus. Im nächsten Schritt erhält man seinen Lizenzschlüssel.

Mit dem Handy navigiert man dann zu http://m.tivi.com und lädt sich die Software herunter. Die Installation startet nach dem Download selbstständig. Wichtig: ich musste die Software auf der SD-Karte (E:) installieren und die Warnung zur Inkompatibilität bestätigen. Eine Installation auf dem Telefon (C:) schlägt komischerweise – trotz ausreichend Speicherplatz – fehl. Nach der Installation steht die Software im Menü unter Programme zur Verfügung. Von wird sie jetzt auch gestartet und als Erstes werden die Einstellungen vorgenommen. Dabei gehe ich davon aus, dass wie im Artikel Projekt Richtfunk: Internet + Telefon beschrieben bereits ein zusätzlicher SIP-Account in der FritzBox (für das Handy) angelegt wurde. Folgende Einstellungen sind vorzunehmen (bei Lizenzschlüssel muss natürlich der soeben erhaltene Key eingetragen werden ):

Nach einem Klick auf OK sollte sich Tivi nun mit dem SIP-Server der Fritzbox verbinden und man kann in WLAN-Reichweite kostenlos telefonieren und auch unter seiner Festnetz-Nummer erreicht werden. Etwas gewöhnungsbedürftig ist nur die Bedienung: man ist immer versucht, mit der grünen Taste abzuheben… was allerdings nicht funktioniert. Stattdessen muss man den Touchscreen bemühen. Davon abgesehen ist Tivi der wohl ausgereifteste SIP-Client für Symbian-Phones ohne eigene SIP-Funktionalität.

Schon lange suche ich nach Alternativen, UMTS ist (in unserem Dorf) gerade mal so schnell wie DSL light und hat noch dazu Traffic-Beschränkungen. LTE sollte erst kommen, dann wieder doch nicht – jedenfalls nicht gleich – und hat außerdem bei der Telekom (der einzige Anbieter, der überhaupt ausbauen wollte) diese nervigen 3- und 5-GB-Grenzen drin. Beim Erreichen der 3 GB wird auf 1024 kbit/s gebremst und bei 5 GB surft man den Rest des Monats mit 384 kbit/s und hat nur 64 (statt 96 bei DSL light) kbit/s Upload. Da meine Schwester viel und gern auf Youtube unterwegs ist, wäre das wohl sowieso schief gegangen. Ebenso wären wahrscheinlich sehr viele Bewohner in der LTE-Zelle bei einem Ausbau auf “Call&Surf via Funk” umgestiegen, was wiederum beim Shared Medium Funk bedeutet, dass für alle die Datenrate sinkt. Als weitere Alternative schien sich erst das im Nachbardorf etablierte WDSL Oberlausitz anzubieten. Der Carrier bietet seinen Kunden den Internetzugang via WLAN an und bezieht es mit Hilfe von 5GHz Richtfunk aus der nächsten größeren Stadt Löbau. Leider ist es für einen so kleinen Anbieter nicht möglich, unrentable Randgebiete anzuschließen und die benötigten 10-15 Kunden bekommt man in einem kleinen Dorf, in dem der Altersdurschnitt irgendwo jenseits der 55 liegt, eben nicht zusammen. Daher fiel auch diese Methode aus.

Parallel zu den alternativen Möglichkeiten habe ich auch auf Lösungen mit dem bisherigen Anschluss gehofft. Der zeigte nämlich eine Leitungskapazität von über 1500 kbit/s an – zwar bei entsprechend hoher Dämpfung, aber was solls. Leider hat die Telekom jahrelang nur über feste Dämpfungsgrenzen geschaltet, sodass ich mich auf offiziellen Start von DSL-RAM gefreut habe (ich habe öfters diesen Thread im Onlinekosten-Forum besucht, um zu sehen, wann es nun endlich los geht). Leider war diese Freude völlig unbegründet, an unserem Anschluss war DSL RAM nicht möglich – zu lange Leitung.

Nach dieser Enttäuschung hatte ich erst mal “die Nase voll” bis ich auf die Idee kam, es auch mal beim Haus meiner Großeltern, nur 1.2km Leitungslänge und etwa 600m Luftlinie entfernt, zu versuchen. Und siehe da: DSL RAM 2000 ist verfügbar. Von diesem Zeitpunkt an plante ich eine Richtfunkstrecke für DSL und Telefon. Etwa 3 Wochen später wurde das Projekt in die Tat umgesetzt.

Hier das Konzept:

Zum Einsatz kommen:

• 1 FritzBox 7270 v3 als DSL-Modem und Router
• 2 Outdoor-Panel-Richtantennen mit 18dbi von Theta
• 2 Koaxkabel N-zu-RP-SMA (H155 Belden Low Loss), 7m
• 2 D-Link DAP 1160 mit RP-SMA-Anschluss als Access-Points für die Richtfunkstrecke
• 1 Fritzbox 7050 aus Altbeständen zur Versorgung des Elternhauses mit WLAN (inkl. Telefon via SIP-Registrar an der FB7270) und als WDS-Basisstation
• 1 “gefritzter” Speedport W501V (für 10 Euro gebraucht bei eBay) als WDS-Repeater
• 1 Siemens Gigaset A400A Trio an der FB7050 (1. Rufnummer)
• 1 altes T-Sinus 620S [ISDN] an der FB7270 (2. Rufnummer)
• 1 namenloses, altes, schnurloses Seniorentelefon an der FB7270 (3. Rufnummer)
• eine ganze Menge Kabel, Schrauben etc.

Die Montage der beiden Panels war insgesamt relativ unkompliziert, ein bisschen rumzirkeln war natürlich nötig. Ausrichten lassen sie sich dank der beigefügten Masthalterung recht frei. Die Ausrichtung selbst konnte ich nur via Durchsatzmessung ausführen weil der DAP 1160 leider keine Signalstärkeanzeige besitzt – hätte ich das vorher gewusst, hätte ich mich wohl für einen TP-Link mit Atheros-Chipsatz entschieden und DD-WRT hochgeflasht. Ich dachte aber, das wäre selbstverständlich… na ja. Die beiden APs sind als Bridge (ohne AP) konfiguriert und per LAN mit den Fritzboxen verbunden. Die Verschlüsselung funktioniert dank gleicher Geräte auf WPA2-Basis.

Während die erste Fritzbox natürlich als Router konfiguriert ist, nutzen die andere Fritzbox und der gefritzte Speedport (Anleitung hier) das Internet der 7270 mit. Die 7050 hat dabei in den WLAN-Settings WPA2-Verschlüsselung und WDS-Basisstation eingestellt. Die Mac-Adresse des gefritzten Speedport ist als Repeater eingetragen. Umgekehrt hat der Speedport die Adresse der 7050 als Basisstation eingetragen und funkt ebenfalls bei gleicher SSID und auf dem gleichen Kanal mit der gleichen Verschlüsselung. Somit haben beide Häuser schon mal WLAN und damit Internet.

Das ISDN-Telefon und das schnurlose Seniorentelefon habe ich ganz einfach an die 7270 angehängt und wie gewohnt über die Telefonieeinstellungen eingerichtet. Beim ISDN-Telefon ist zu beachten, dass man im Telefon bzw. an der Basisstation selbst nochmal die entsprechende MSN einstellen muss. Sonst klingelt es bei allen Anrufen. Für das andere Haus hatte ich mir eine Lösung über WLAN ausgedacht: 2 TC-300 (aka Pirelli DP-L10) sollten als eigenständige Handgeräte am WLAN angemeldet werden und direkte Telefonie ermöglichen. Für das DP-L10 hatte ich mich vor allem wegen des günstigen Preises entschieden; andere WLAN-Telefone, z.B. aus der Nokia E- oder N-Serie, kosten das fünf- bis sechsfache. Nun ja, das hat auch einen Grund. Nach 2 Tagen Herumexperimentieren ist es mir nicht geglückt, beide Telefone einzubuchen. Sie waren in der FB als WLAN-Telefone eingerichtet, eines anmelden und darüber telefonieren ging. Die Sprachqualität ist allerdings miserabel (egal wo man sich befindet, auch ½m neben der Fritzbox), der Akku hält gerade einmal einen Tag durch und die Reichweite ist sehr gering. Zudem wechseln die Telefone nicht automatisch den AP (zum Speedport bzw. zur Fritzbox), wenn dieser ein besseres Signal liefern würde. Alles in Allem ist das TC-300 ein echter Reinfall gewesen, daher habe ich mich entschieden, das Gerät zurück zu geben und dafür das Gigaset A400A Trio bestellt. Das wird an die Fritzbox 7050 gehängt und diese wird als WLAN-Telefon in der 7270 eingerichtet. Wie das genau funktioniert, verrät AVM in diesem .pdf (lustigerweise mit dem Namen 11833).

So sind nun letztendlich alle zufrieden und insgesamt 3 Haushalte werden mittels eines Call&Surf-Pakets mit Internet und Telefon versorgt. Eine, wie ich finde, sehr elegante und kostensparende Alternative zu LTE & Co. Wie man auf den Screenshots sehen kann, liegt Vollsync trotz recht hoher Dämpfungswerte und eines zerhackten Spektrums an. Die SNR ließe theoretsich sogar noch auf etwas mehr Speed hoffen, zunächst ist die Versechsfachung der Geschwindigkeit ein toller Erfolg.

Zum Schluss noch ein paar Bilder vom Projekt:

Das Programm tar enthält eine exclude-Funktion. Also nutzen wir doch einfach dieses:

1

tar -cvf - --exclude dir1 --exclude dir2 --exclude file1.ext --exclude file2.ext /path/to/source | (cd /path/to/destination; tar -xvf -)

Danke für diesen Tipp an vsemaska von linuxforums.org.

Wenn zum Beispiel das CMS Joomla eine Komponente oder ein Modul über das Webinterface installiert bekommt so haben die Dateien, die installiert werden, als “Owner” den User, unter dem der Webserver läuft (meist www-data). Andererseits hat ein manuell über FTP eingespieltes Template als “Owner” den Hosting-Nutzer. Auf den meisten Systemen kommt dazu eine default-umask von 022, die allen neu erstellten Dateien ausschließlich Schreibrechte für den Ersteller/Besitzer der Datei zugesteht. Das könnte man zwar theoretisch ändern, würde damit aber die Sicherheit bei mehreren Nutzern kompromittieren (z.B. indem man die Nutzer und www-data einer Gruppe zuordnet, die Schreibrechte hat).

Alles in allem eine sehr unbefriedigende Lösung. Aber es gibt Abhilfe: ACLs (Access Control Lists) erlauben die feingranulare Einstellung der Rechte auf Nutzerebene wie auch in Gruppen. Mit ihnen lassen sich Konstrukte schaffen wie “www-data und Hostingnutzer haben rwx-Rechte” – und das auch für neu erstellte Dateien. Doch der Reihe nach.

Für die Nutzung von ACLs unter Ubuntu/Debian braucht es einen einigermaßen modernen Kernel (>2.5.46, ob man diesen Kernel von 2002 noch “einigermaßen modern” nennen kann lasse ich jetzt mal dahingestellt ) und die Partitionen müssen mit ext2 oder höher formatiert sein. In der /etc/fstab muss bei den Mountoptions aller Partitionen, mit denen ACLs genutzt werden sollen, der Parameter acl hinzugefügt werden, z.B.:

1
2
3
4
5
6
7

# /etc/fstab: static file system information.
#
# <file system> <mount point>   <type>  <options>       <dump>  <pass>
proc            /proc           proc    defaults        0       0
UUID=c1234f7f-fb32-4199-342a-4a12342f9a9d       /               ext3    defaults,usrquota,acl   0       1
UUID=f12349d1-d7e1-4ce5-4f3w-ddf971234b7       /boot           ext2    defaults        0       2
UUID=a1234b2b-b6bb-4572-33df-9351234335a0       none            swap    sw              0       0

Für die Bootpartition und die Swap-Partition brauchen wir natürlich keine ACLs, daher erfolgt der Eintrag nur auf der ersten Festplatte. Nach einer Änderung an der fstab muss das System neu gestartet werden um die Mountoptions zu übernehmen. Alternativ kann man natürlich auch den entsprechenden Mountpoint aushängen und manuell mit dem zusätzlichen Parameter neu mounten.

Als nächstes gehen wir in das Verzeichnis, welches die neuen ACLs erhalten soll und vergeben sie entsprechend unseren Wünschen:

1
2
3

cd /var/www/vhosts/username/
setfacl -R -m u::rwX,u:www-data:rwX,u:username:rwX .
setfacl -R -d -m u::rwX,u:www-data:rwX,u:username:rwX .

Die Zeile 2 des Codeschnipsels sorgt dafür, dass die User www-data und username Lese-, Schreib- und Ausführungsrechte für bereits bestehende Dateien/Ordner im Verzeichnis und allen Unterverzeichnissen erhalten. Das groß geschriebene “X” sorgt dabei für eine automatische Berechnung der Maske, ohne die es zu Einschränkungen im Zugriff kommen kann. Zeile 3 macht das Gleiche wie Zeile 2, nur für neu erstellte Objekte (Parameter d = default). Mit Hilfe dieses Konstrukts hat man eine Umgebung geschaffen, in der der Nutzer sich mit FTP und PHP-Fileuploads austoben kann und doch die Sicherheit des Systems gewahrt bleibt. Zugleich haben andere Nutzer nach wie vor keinen Zugriff auf die Dateien und Ordner von Benutzer username.

Für den “Hausgebrauch” reichen diese Befehle schon aus, um ein komfortables Arbeiten zu ermöglichen. Wer aber noch mehr erfahren möchte, dem sei die Seite über ACLs im Ubuntu-Wiki empfohlen. Dort wird u.a. ausführlich erklärt, wie man mit Gruppenrechten hantiert, wie man erstellte ACLs wieder los wird und wie man ein Backup seiner Listen anlegen kann.

Glücklicherweise hat dann jemand – wahrscheinlich ein Mitarbeiter von MSI – ein Video gepostet, in dem das Zerlegen des baugleichen Modells GX620 beschrieben wird. Mit dieser Anleitung im Rücken habe ich das Notebook zerlegt und dabei fiel mir auf, dass es die CPU beim Anheben der Heatpipe direkt mit aus dem Sockel gezogen hat, so fest verband das Wärmeleitpad Heatpipe und Prozessor. Um aber die CPU später wieder korrekt einsetzen zu können musste ich aber Heatpipe und CPU trennen (der Feststellmechanismus war sonst verdeckt).

Dabei hat mir ein ganz einfacher Trick (gepostet in diesem Forum) geholfen, den ich hier weitergeben möchte: Man nehme einen Fön und erhitze die CPU so stark, dass man sie gerade noch anfassen kann. Dann dreht man einfach ein bisschen und zack: die CPU ist ab.

Nach dem Auftragen der neuen Wärmeleitpaste (ich kann hier die von mir verwendete Arctic MX-2 empfehlen) und dem Zusammensetzen schnurrt der Q9000 nun wieder mit akzeptablen 47° C im Leerlauf – bei 30° Raumtemperatur.