Dateien eines Jahres archivieren

Heute stand ich (mal wieder) vor der Aufgabe, in einem Verzeichnis alle Dateien vom Vorjahr zu archivieren.

Im Artikel „Dateien an Hand des Datums und der Uhrzeit finden“ habe ich gezeigt, wie man mit find Dateien eines bestimmten Zeitraums finden kann. Da ich aber für die Archivierung keine Rekursion benötige, kann ich das Ganze etwas einfacher mit einem Einzeiler machen:

stat -c '%n Date:%y' * | perl -n -e 'print "$1
" if /^(.+)sDate:2008/' \n | zip archiv_2008.zip -@

Ich verwende hier stat, um das Ausgabeformat bestimmen zu können. Da die Dateinamen Leerzeichen enthalten können, kann ich keine Leerzeichen als Trenner zwischen Name und Datum verwenden, daher die Kennzeichnung mittels „Date:“. Perl filtert mir erstens alle Dateien von 2008 heraus und gibt auch nur den Dateinamen aus. Zip liest diese von der Standardeingabe, wenn die Dateiliste als -@ angegeben ist.

Soll Zip die Dateien auch gleich entsorgen, so kann man das über die Option -m erreichen.

Artikel von Beta-Blogger nach WordPress umziehen

So, ich habe es geschafft, alle Artikel des alten Blog-Systems Beta-Blogger zu exportieren und diese in WordPress wieder zu importieren. Da ich keine direkte Übertragungsmöglichkeit gefunden habe, habe ich den Weg über CSV gewählt. Es gibt ein halbwegs brauchbares CSV-Import-Plugin und die Artikel aus dem alten Blog ließen sich mit dem folgenden PHP-Script als CSV exportieren:

<?php
require 'bb_core.php';

/* see http://de.php.net/manual/de/function.htmlentities.php#90111 */
function htmlButTags($str) {
  // Take all the html entities
  $caracteres = get_html_translation_table(HTML_ENTITIES);
  // Find out the "tags" entities
  $remover = get_html_translation_table(HTML_SPECIALCHARS);
  // Spit out the tags entities from the original table
  $caracteres = array_diff($caracteres, $remover);
  // Translate the string....
  $str = strtr($str, $caracteres);
  // And that's it!
  // oo now amps
  $str = preg_replace("/&(?![A-Za-z]{0,4}w{2,3};|#[0-9]{2,3};)/","&amp;" , $str);
  return $str;
}

$entries = $blog->get_items('entry', NULL, 1000) or print $lang->no_entries;

print("wp_title|wp_post_date|wp_category|wp_content|field1|field2|field3
");
foreach ($entries as $entry) {
  // Tags: Leerzeichen in "" ersetzen und " entfernen
  $tags =  preg_replace('/"(w+) (w+)"/', '$1=$2', $entry->tags);
  // Tags durch Kommata trennen
  $tags = str_replace(" ", ", ", $tags);
  // oben ersetzte Leerzeichen zurück wandeln
  $tags = str_replace("=", " ", $tags);
  $title = htmlButTags($entry->title);
  $date = strftime("%Y-%m-%d %T", $entry->date);
  $body = preg_replace('/
/', '&#x000A', htmlButTags($entry->body));
  $body = preg_replace('/src=["']media2/', 'src="/wp/wp-content/uploads/2009/09', $body);
  // Pipes müssen escaped werden
  $body = preg_replace('/|/', '|', $body);
  $body2 = preg_replace('/
/', '
', htmlspecialchars($entry->body));
  $teaser = htmlButTags($entry->topic);
  $category = htmlspecialchars($entry->category);

  print("$title|$date|$category|$body|$tags|$teaser|
");

}

?>

Damit die Leerzeichen, die beim Export mit ‚&#x000A‘ escaped wurden, beim Import entsprechend wieder hergestellt werden, musste ich das CSV-Import-Plugin noch geringfügig anpassen und eine Zeile einfügen:

$post_content = str_replace('&#x000A', "
", $post_content);

(Das komplette, angepasste Plugin gibt es hier.)

Leider kann das Import-Plugin keine Tags importieren. Ich habe diese daher im ersten Benutzerfeld abgelegt, so dass sie dann beim Editieren des Artikels per Cut & Paste in das Tag-Feld übertragen werden können. Das ist sicherlich nicht der Hit und bedeutet, dass man jeden Artikel anfassen muss. Aber bei 34 Artikeln ist das noch machbar.

Nur einen bestimmten Zeitabschnitt einer Logdateien ausgeben

In einer Logdatei lässt sich ja prima mit grep nach einer Zeichenkette suchen. Was aber, wenn man nur einen bestimmten Zeitraum der Logdatei durchsuchen möchte?

Nun, da hilft uns mal wieder das Universalwerkzeug Perl mit seinem sog. Bereichsoperator (..). Wird dieser nämlich im skalaren Kontext verwendet, liefert er uns solange falsch, solange der linke Ausdruck falsch ist. Sobald der linke Ausdruck (einmal) wahr wird, liefert der Bereichsoperator solange wahr zurück, bis der rechte Ausdruck wahr wird. Er ist also so etwas wie ein bistabiler Schalter mit einer Einschalt- und einer Ausschaltbedingung (der Elektroniker nennt so etwas ein Flip-Flop). Genug der Theorie, hier die praktische Anwendung für unseren Fall:

perl -n -e 'print $_ if /^Aug 18/ .. /^Aug 31/' /var/log/messages

Dies liefert uns alle Einträge vom 18. August bis zum 31. August (oder bis zum Ende der Datei, wenn heute erst der 28. August ist).

Mit einem nachgeschalteten grep kann man nun prima in diesem Abschnitt suchen. Hier ein Beispiel, welches alle anfragende Rechner für den o.g. Zeitraum aus der Logdatei des DNS-Servers ermittelt:

perl -n -e 'print $_ if /^Aug 18/ .. /^Aug 31/' named.queries | sed -n 's/^.* client ([^#]*)#.*$/1/p' | sort | uniq

Umstellung auf WordPress

Nachdem die Seite nun endlich auf eine eigene Domain umgezogen ist, werde ich das Blog nun auch nach WordPress überführen.

Das kann aber noch was dauern, weil ich nicht weiß, wie ich die Artikel am Besten aus dem alten Blog raus und ins neue rein bekommen. Zur Not von Hand — es sind ja nur ca. 30 Artikel.

Script-Fehler beim IE6 finden

Meldet der IE6 einen Javascript-Fehler, der sich im Firefox nicht nachvollziehen lässt, so wird es schwierig. Der IE6 meldet zwar, er hätte in der Datei xy.php in Zeile x bei Zeichen y einen Fehler gefunden, aber diese Angaben sind irreführend. Oder doch nicht? Wie man dem Fehler auf die Spur kommen kann zeige ich hier.

Beim Aufrufen einer Seite wird zum Beispiel die folgende Fehlermeldung angezeigt:

Screenshot der 1. Fehlermeldung

Im Prinzip ist die Angabe von Zeile und Spalte gar nicht so verkehrt, nur die Datei-Angabe stimmt meist überhaupt nicht, da eine HTML-Seite zum einen oft aus verschiedenen Teilen per PHP zusammengesetzt wird und zum anderen der Javascript-Code häufig in eigene Dateien ausgelagert ist.

Um nun herauszubekommen, in welcher Datei der Teufel im Detail steckt, muss man den Debug-Modus aktivieren und die Anzeige der Script-Fehler ausschalten. Dies geschieht in Extras » Internetoptionen » Erweitert. Dort werden, wie unten gezeigt, die Häkchen bei »Skriptdebugging deaktivieren« und bei »Skriptfehler anzeigen« entfernt. Danach muss der IE neu gestartet werden, damit die Änderungen wirksam werden.

Screenshot der Internetopionen des IE6

Wird nun die betreffende Seite erneut aufgerufen, sieht die Fehlermeldung etwas anders aus:

Screenshot der 2. Fehlermeldung

Hier ist nun auch erstaunlicher Weise von Zeile 14 die Rede! Klick man nun auf »Ja«, wird der IE-Debugger gestartet und die Datei geladen und angezeigt, in der der Internet-Explorer den Fehler gefunden hat. Der Cursor wird allerdings an die Position gesetzt, die in der ersten Fehlermeldung angezeigt wurde: Zeile 15, Spalte 22.

Ausschnitt der Debug-Anzeige

Wenn wir uns aber an die Angabe aus der zweiten Fehlermeldung (Zeile 14) erinnern und unser Augenmerk auf die Zeile über dem Cursor richten, sehen wir dort in Spalte 22 einen zweiten Punkt, der dort nicht hingehört. Dies ist der Fehler!

Das Verfahren ist etwas umständlich, aber immerhin zielführend. Und wenn man sich erst einmal daran gewöhnt bzw. damit abgefunden hat, ist es recht nützlich.

Leerzeichen bei For-In-Schleifen in der bash

Im Artikel Dateinamen mit Leerzeichen auf der Kommandozeile verarbeiten habe ich beschrieben, wie man Ärger mit Leerzeichen in Dateinamen umgeht. Heute geht es um Daten, die innerhalb einer For-In-Schleife aus einer Datei gelesen werden und die Leerzeichen enthalten.

Wenn wir eine Datei mit folgendem Inhalt haben:

klaus rechner1
martin rechner3
dieter rechner7

Und wir lassen diese von folgendem Script einlesen und wieder ausgeben (was natürlich recht sinnfrei ist, hier aber nur zur Veranschaulichung dienen soll):

#!/bin/bash
for ZEILE in `cat daten`
do
  echo $ZEILE
done

Dann kommt sowas raus:

klaus
rechner1
martin
rechner3
dieter
rechner7

Durch die Leerzeichen werden die Daten-Zeilen zerteilt. Damit das nicht passiert, setzt man den „Input Field Separator“ $IFS auf ‚
‚ (Standard ist ein “
„):

#!/bin/bash
Newline=$'
'
IFS=$Newline
for ZEILE in `cat daten`
do
echo $ZEILE
done
IFS=

Dann sieht das Ergebnis wie erwartet und gewünscht aus:

klaus rechner1
martin rechner3
dieter rechner7

Alle Fehlermeldungen in einem Script umleiten

Man kann in einem Shell-Script ja Ausgaben, die an den Standard-Fehler-Kanal STDERR gehen, mit 2>>dateiname.log in eine Datei umleiten. Dies muss aber für jeden Befehl einzeln gemacht werden. Es gibt aber bei der Bash eine Methode, die Umleitung für das gesamte Script zu machen.

Dazu nutzt man eine Spezialform des Befehls exec: Werden als Parameter nur Umleitungen angegeben, so leitet die Shell die gewünschten Kanäle permanent um.

#!/bin/bash
exec 2>> dateiname.log

echo "Normale Ausgabe"
echo "An stderr" >&2
echo "das folgende macht einen Fehler"
TEST=`gibtsnicht  `
echo "Das geht auch in Pipes:"
LINES=`lsx -1 $TREE | egrepx -v '^.+$' | wc -l`

Startet man das Script, so erhält man auf der Konsole diese Ausgabe:

Normale Ausgabe
das folgende macht einen Fehler
Das geht auch in Pipes:

Das sind die Ausgaben auf der Standard-Ausgabe.

Die Log-Datei enthält die Ausgabe der Fehlermeldungen:

An stderr
./logtest: line 7: gibtsnicht: command not found
./logtest: line 9: lsx: command not found
./logtest: line 9: egrepx: command not found

Sollen alle Ausgaben in die Logdatei umgeleitet werden, so verwendet man

exec >> dateiname.log 2>&1

SSH-Key auf einen anderen Rechner übertragen

SSH ist eine feine Sache, um sicher auf einen anderen Rechner zu zugreifen. Häufig wird jedoch die Passwortabfrage genutzt, die aber nicht so sicher und komfortabel wie Key-Methode.

Damit man diese aber nutzen kann, muss der Public-Key auf dem Zielrechner in die Datei authorized_keys eingetragen werden. Aber auch das lässt sich einfach und komfortabel per SSH machen:

cat ~/.ssh/id_dsa.pub | ssh user@zielrechner \n  "cd ~/.ssh && cat >> authorized_keys"

Nun wird man beim nächsten Login nicht mehr nach dem Passwort des Users auf dem Zielrechner gefragt, sondern nach der sog. Passphrase, also dem Passwort, mit dem der private Teil des oben übertragenen öffentlichen Schlüssels verschlüsselt ist.

um die Sicherheit weiter zu erhöhen, kann man nun den Zugang per Passwortabfrage verbieten, indem man in der sshd_config PasswordAuthentication no einträgt. Man sollte dann aber auch UsePAM no setzen, sonst hat PasswordAuthentication kein Effekt.