Archiv der Kategorie: Kurztipps

WordPress und 1&1

Wer sein WordPress bei 1&1 mit MySqlDB einrichten will, bekommt oft die Fehlermeldung (”500 Interner Serverfehler”). Vorallem bei der Installation eines PlugIns bleibt WordPress stehen  oder reagierte seltsam, wenn man die PlugIn-Seite aufruft.

Die Lösung des Problems liegt in der .htaccess Datei im WordPress-Verzeichnis in die folgende Zeilen eingefügt werden müssen:

# PHP5 auf 1und1 einschalten
AddType x-mapp-php5 .php
AddHandler x-mapp-php5 .php

vi-Kurzreferenz

Der vi-Editor ist der wohl wichtigste Unix-Editor.
Er findet sich in jeder noch so rudimentären Installation, auf Notfalldisketten und verschiedenen Unix-Derivaten.
Steht einmal keine Alternative in Form von Midnight-Commander oder Joe zur Verfügung,
ist guter Rat teuer. Die folgende Kurzreferenz hilft, vi und Co in den Griff zu bekommen.

Achtung der optionale numerische Wert »Stellen« bezeichnet die Stellen der Positionen,
die sich der Cursor bewegen soll. Default ist 1.

Navigation:
[Stellen] [Ctrl H] Cursor links
[Stellen] [Ctrl Leertaste] Cursor rechts
[Stellen] [Ctrl N] Cursor abwärts
[Stellen] [Ctrl P] Cursor aufwärts
[Stellen] [Ctrl D] eine halbe Bildschirmseite nach unten blättern
[Stellen] [Ctrl U] eine halbe Bildschirmseite nach oben blättern
[Stellen] [Ctrl G] zum Ende blättern

/Suchbegriff/ sucht eine Textstelle

Ein Druck auf [Esc] wechselt in den Kommandomodus:

a Insert-Modus (»after«), die Zeichen werden hinter der aktuellen Cursorposition eingegeben.
i Insert-Modus (»before«), die Zeichen werden vor der aktuellen Cursorposition eingegeben.
r überschreibt das aktuelle Zeichen
R wechselt in den Eingabemodus und überschreibt alle Zeichen ab der aktuellen Cursorposition mit der neuen Eingabe
x aktuelles Zeichen löschen
dd löscht die aktuelle Zeile
u nimmt den letzten Befehl zurück
:help vi-Hilfe anzeigen
:w Datei sichern
:q vi verlassen
:q! vi auf jeden Fall verlassen; Datei wird nicht gesichert, eine eventuelle Nachfrage wird übergangen
:wq Datei sichern und vi verlassen

Wiederherstellen der RPM-Datenbank

Sollte die RPM Datenbank beschädigt sein gibt es eine schnelle möglichkeit diese wieder zu reaktivieren.

  1. Ãœber den Befehl rpm –rebuilddb kann die DB wieder Repariert werden.
  2. Sollte diese nicht möglich sein folgt Stufe II
  1. rm -f /var/lib/rpm/__db* (bei Suse sollte es nur eine geben).
  2. db_verify /var/lib/rpm/Packages
  3. rpm –rebuilddb

Info:
Mit rebuilddb ist möglich, eine defekte Datenbank wieder herzustellen – es wird zumindest versucht die Datenbank zu reparieren, wie groß die Erfolgsquote ist, kann ich leider nicht beurteilen.

Mit initdb ist es möglich eine RPM Datenbank zu erzeugen. Es ist auch möglich eine zweite Datenbank im System zu erzeugen. Dies kann zum Test von Paketen oder Programmen nützlich sein, es ist dann aber notwendig einen anderen Pfad für die Datenbank anzugeben. Existiert bereits eine Datenbank, wird diese durch die Verwendung von –initdb nicht überschrieben. Die von RPM standardmäßig benutzte Datenbank befindet sich unter dem Verzeichnis /var/lib/rpm/

Apache: exit signal File size limit exceeded (25)

Es gibt manchmal Fehler die eigentlich nicht passieren dürften, bei der Kontrolle der Logfiles stolperte ich auf folgende Fehlermeldung: „child pid 8914 exit signal File size limit exceeded (25)“

Die Meldung machte mich stutzig, da ja alle Logfiles in der Datei (SuSE) /etc/logrotate.d/apache2
eingetragen sein sollten. Durch eine kleines Script überprüfte ich mein Apache Konfigurations File mit:

‚du -h $(cat yast2_vhosts.conf | grep -v „#“ | grep „CustomLog“ | awk ‚{print $2}‘) | grep „G“ ‚

Spontan tauchten in den Konsole drei Logfiles mit einer Größe von 11Gb auf.
Die Lösung war einfach, Logs verschieben / umbenennen und den Webserver einen Restart verordnen. Die Datei „/etc/logrotate.d/apache2“ durch die Fehlenden Einträge ersetzen fertig.

Die einzige Frag die offen bleibt: „Warum standen die Logs nicht in der Datei?“
Und die Erkenntnis, das Apache2 nur Files bis 2 GB verarbeiten kann.

Mysql Datenbank Backup

Eine elegantere Möglichkeit bietet da das kleine Tool mysqldump, insbesondere wenn man keinen direkten Zugriff auf das mySQL Datenverzeichnis hat:

bash$ mysqldump -h localhost -u mysqluser -pmysqlpass --opt databasename > dumpfile.sql

Erstellt ein Backup der Datenbank ‘databasename’ in der Datei dumfile.sql. Anzugeben dabei natürlich der Hostname (-h), Datenbankuser und -passwort (-u -p) und die zu sichernde mySQL-Datenbank (–opt).

Um das Backup bzw. den Dump wieder einzuspielen geht man folgendermaßen vor:

bash$ mysql -h localhost -u mysqluser -D databasename -pmysqlpass < dumpfile.sql