Kategorien

Link zu externer URL funktioniert mit Referer nicht

Mit großer Überraschung musste ich feststellen, dass obwohl ich in typo3 einen Link zu einer externen URL für meine Domain effinger.org eingerichtet hatte, dieser Link zwar beim Eingeben in die Adress-Leiste des Browsers ohne Probleme funktionierte, aber nicht als ich die Seite von Google aus ausrufen wollte. Irgendwie musste also der Referer die Ursache des Übels sein. Nach langer Suche fand ich schließlich einen Eintrag im Bugtracker. Es gibt zwar einen Workaround, in dem man im Installationstool von Typo3 unter „All Configuration“ in [Sys] den [doNotCheckReferer]=1 setzt.  Da der Referercheck beim Arbeiten mit dem Backend eine etwas höhere Sicherheit bietet, habe ich bei mir allerdings eine Lösung mit htaccess bevorzugt:

#Anfragen an http://effinger.org/ und http://www.effinger.org/ ins Blog-Verzeichnis umleiten
#Alle anderen Anfragen z.B. an http://www.effinger.org/index.html bleiben unbeachtet
RewriteCond %{HTTP_HOST} ^(www\.)?effinger\.org$ [NC]
RewriteCond %{REQUEST_URI} ^/$
RewriteRule ^(.*)$ blog/ [L]

Templavoila: Sidebar statt leerem Inhalt anzeigen

Auf einer Webseite wollte ich für den Fall, dass der Redakteur bei einer Spalte oder einem Content-Element keinen Inhalt hinterlegt hat automatisch den Inhalt einer bestimmten Seite anzeigen. Nach langem Suchen habe ich es schließlich geschafft, in dem ich die Extension flexform_getfield verwendet habe. Weitergeholfen hat mir dabei auch ein Forumsbeitrag auf typo3.net.

In der DS-XML-Datei habe ich folgende Zeilen

10 {
	source.current=1
	tables = tt_content
	wrap = <!--TYPO3SEARCH_begin--> | <!--TYPO3SEARCH_end--> 
}

in

	10 {
		source.current=1
		tables = tt_content
		#Typo3-Search nur ausgeben, wenn Inhalt vorhanden ist - siehe http://www.typo3-jack.net/typo3-dev-lists-netfielders-de/2404-typo3-dev-typoscript-stdwrap-ifempty-but-no-stdwrap-ifisset.html
		stdWrap {
			required = 1
			wrap = <!--TYPO3SEARCH_begin-->|<!--TYPO3SEARCH_end-->
		}
		stdWrap.ifEmpty.cObject = COA
		stdWrap.ifEmpty.cObject =< temp.getNews
	} 

abgeändert. Das obige Konstrukt temp.getNews sollte dabei auf den Inhalt einer ebenfalls vom Redakteur bearbeitbaren Seite verweisen. Das habe ich folgendermaßen bewerkstelligt:

temp.getNewsID = USER
temp.getNewsID {
	userFunc = tx_flexformgetfield_pi1->main
	field = field_centercontent
	recLevel=4
	#UID der Seite mit den News
	uid=149
}
temp.getNews = RECORDS
temp.getNews.source.cObject < temp.getNewsID
temp.getNews.tables = tt_content

Es hat ewig gedauert, bis ich herausgefunden hatte, dass man nur durch die Änderung von source.cObject die NewsID übergeben kann und nicht etwa durch temp.getNews.source < temp.getNewsID.

Daten von mit LUKS-verschlüsselter Platte retten

Nachdem der Ubuntu-Installer meine Platte /dev/hda, die in verschlüsselter Form das Backup enthielt, durch die Installation von grub in den Bootsektor unbrauchbar gemacht hatte (LUKS-Header überschrieben). Musste ich mich an die Wiederherstellung der Daten von der Platte machen, auf die ich das System neu installiert hatte. Gott sei Dank hatte ich bei der Neupartitionierung meines Systems andere Partitionsgrößen gewählt, so dass noch Hoffnung bestand, dass die LUKS-Header der ehemaligen Partitionen intakt sein könnte. Meine Rettungsstrategie bestand darin, zunächst zu überprüfen, ob dieser Header noch vorhanden ist, um dann ggfs. über ein Loop-Back Device die Entschlüsselung vorzunehmen und zu schauen, ob noch etwas zu retten ist. Dazu verwendete ich die aktuelle Knoppix-CD.

Mein neues System hatte ich auf /dev/sda installiert. Im Zuge der Neuinstallation hatte ich vier Partitionen erstellt: /dev/sda1 bis /dev/sda4, die teilweise auch verschlüsselt sind. Auf der Platte /dev/sda musste ich also nach meinem alten LUKS-Header für die Datenpartition suchen. Bevor man jedoch mit der Suche loslegt, sollte man auf Nummer sicher gehen und die Partition in den nur-Lesemodus versetzen.

sudo chmod 400 /dev/sda*

Mit dem Hex-Editor hexedit suchen wir nun nach LUKS-Headern:

sudo hexedit /dev/sda

Mit der Taste <Tab> erstmal in den ASCII-Teil wechseln und dann mit der Tastenkombination <Strg>+<S> die Suche nach dem Wort LUKS starten. Sobald ich einen Header gefunden hatte, musste ich überprüfen, ob es ein Header der neuen verschlüsselten Partition war oder aber der meiner alten, den ich verzweifelt suchte. Dazu öffnete ich dann jeweils die anderen Partitionen im Hexeditor und verglich die Zeichenfolgen, die ein paar Bytes nach dem Schlüsselwort LUKS kommen.

sudo hexedit /dev/sda1

Nachdem ich an dem Offset 0x2E44CCC00 den entsprechenden Header meiner alten Partition gefunden hatte, musste ich noch herausfinden, wie groß die alte Partition war. Ich hatte Glück, da die Partition den gesamten Rest der Festplatte einnahm und somit 237639177216 Bytes groß gewesen sein musste.

Mit diesen Informationen kann man nun mittels losetup ein Loopback-Device erzeugen, das genau auf den Teil verweist, der die urpsrüngliche verschlüsselte Partition ausgemacht hat.

sudo losetup -o @0x2E44CCC00 -s 237639177216 /dev/loop1 /dev/sda

Nun kann man das Loopback-Device ebenfalls read-only setzen und mit cryptsetup öffnen

sudo chmod 400 /dev/loop1
sudo cryptsetup -d /path/to/key luksOpen /dev/loop1 cryptbackup

Die Partition können wir nun mit mounten mit einem

mount -t jfs -o ro /dev/mapper/cryptbackup /mnt/recover

oder als Image sichern (Achtung unverschlüsselt!)

dd if=/dev/mapper/cryptbackup of=/location/to/backup.img bs=10M

Den Fortschritt von dd kann man übrigens mit

while /bin/true; do sleep 5; kill -USR1 DD-PID; done

verfolgen.

Programme mit stow verwalten

Obwohl die meisten Linux-Programme in einer Paket-Version für Ubuntu erhältlich sind und man sich deshalb keine Gedanken um die Installation machen muss, gibt es doch das eine oder andere Programm, das eben noch nicht in einer Paket-Version erhältlich ist. Diese Programme werden dann üblicherweise in /usr/local installiert. In diesem Verzeichnis kann man sehr schnell den Überblick verlieren und ist außerdem aufgeschmissen, wenn die Deinstallationsroutine unvollständig ist oder versagt. Aus diesem Grund wurde stow entwickelt. Dabei werden die Programme nicht /usr/local, sondern in /usr/local/programmname installiert. stow erzeugt anschließend entsprechende Symlinks zu den einzelnen Dateien.

Am Beispiel von RubyRipper exerzieren wir das nun durch:

  1. Erstmal sicher stellen, dass alle notwendigen Pakete vorhanden sind:
    sudo aptitude install cd-discid cdparanoia ruby ruby-pkg-tools libgettext-ruby1.8 libgtk2-ruby
  2. Die neueste Version auf der RubyRipper-Webseite herunterladen
  3. Die Datei entpacken und in das Verzeichnis wechseln
    tar xjvf rubyripper-0.5.3.tar.bz2
    cd rubyripper-0.5.3
  4. Wichtig: Zielverzeichnis konfigurieren
    ./configure --enable-lang-all --enable-gtk2 --enable-cli --prefix=/usr/local/rubyripper
  5. Programm installieren
    sudo make install
  6. Stow die Verknüpfungen anlegen lassen
    cd /usr/local
    sudo stow -R rubyripper

    Fertig!

Deinstallation

  1. Verweise mit stow entfernen:
    cd /usr/local
    sudo stow -D rubyripper
  2. Deinstallation mit
    sudo make uninstall

Encspot für Linux

Encspot ist ein Programm, mit dem man feststellen kann, mit welchem MP3-Encoder eine MP3-Datei erstellt wurde. Es ist sinnvoll, um indirekt die Qualität der MP3-Datei zu beurteilen. Insbesondere Dateien, die mit dem MP3-Encoder von Xing erstellt wurden weisen eine schlechtere Qualität als die mit LAME erstellten auf. Vor einigen Jahren wurde deshalb von GuerillaSoft die Software EncSpot entwickelt, die ermitteln sollte, welcher Encoder eingesetzt wurde. Das Programm war zunächst nur für Windows verfügbar. Mittlerweile habe ich eine Linux-Version bei daemon’s horn unter http://hype.sourceforge.jp/f/dists/sarge/backports/ gefunden.

Damit die Dateien auch noch in ferner Zukunft verfügbar sind, habe ich sie auch nochmal bei mir auf dem Server abgelegt:

encspot_2.01-1_dh.0.diff.gz

encspot_2.01-1_dh.0.dsc

encspot_2.01-1_dh.0_i386.deb

encspot_2.01.orig.tar.gz

EncSpot_Console_2.01 (für Windows).zip