Headerbild

PDF-Dateigröße schnell und einfach reduzieren

Da ich absolut kein Freund von Papier im Office bin und möglichst alles als PDF-Dokument auf der Platte und im Netz* aufbewahre, scanne ich fast alles, was hier an wichtigen Dingen in Papierform ankommt ein um es eben so zu archivieren. Allerdings ist die Dateigröße solcher gescannten Dokumente relativ groß und so habe ich mich auf die Suche nach Lösungen gemacht:

Lösung 1: Nach dem Scannen mit Preview.app im “Save-As”-Dialog einen Quarz-Filter auswählen um die Größe zu verringern.

  • Pro: Built-In-Lösung, keine weiteren Apps nötig, keine Anschaffungskosten
  • Contra: nur via Automatorscript automatisierbar, OSX-Only, in meinem Test absolut grottige Qualität, nicht auf Headless-System einsetzbar

Lösung 2: Adobe Acrobat hat eine integrierte Funktion um die Dateigröße zu verringern, die allerdings wie der Name schon sagt nur in der Bezahlversion vorhanden ist und nicht im Acrobat Reader.

  • Pro: sehr gute Verkleinerung der Dateien, sehr gute Qualität des Dokuments nach der Verkleinerung, unterstützt zusätzlich Texterkennung
  • Contra: sehr hohe Anschaffungskosten, nicht oder nur schlecht automatisierbar, hoher Resourcenverbrauch, nicht auf Headless-System einsetzbar, zusätzliche Software nötig, kein Linux-Einsatz

Lösung 3: Ein kleines Bash-Script, welches GhostScript aufruft um die Dateien zu verkleinern. Dabei werden einige Parameter an GhostScript übergeben und der Rest passiert in recht kurzer Zeit (abhängig von der Ursprungsgröße) von alleine.

  • Pro: freie Software, zu 100% automatisierbar, lauffähig auf Headless-Systemen, minimale bis keine Qualitätsunterschiede zum Original, hohe Effizienz was die Verkleinerung der Dateigröße angeht
  • Contra: benötigt auf einigen Systemen zusätzliche Software

Meine damit bevorzugte Lösung ist definitiv die Lösung 3, da ich sie Serverseitig ausführen kann, sie sowohl auf OSX als auch auf Linux nutzen kann und sie gute Resultate bringt. Die Kompression der Datei ist dabei nur minimal schlechter als beim Adobe Acrobat aber dafür spart diese Lösung sowohl Zeit durch die Automatisierung als auch Geld dadurch, dass es freie Software ist.

Wen das bei mir eingesetzte Script interessiert, welches ursprünglich aus dem Ubuntu-Forum stammt, der darf hier kopieren:

#!/bin/bash
gs -sDEVICE=pdfwrite -dCompatibilityLevel=1.4 -dPDFSETTINGS=/ebook -dNOPAUSE -dQUIET -dBATCH -sOutputFile=${1%\.pdf}-small.pdf $1

Der einzige Punkt, der mir damit noch fehlt ist, dass leider keine OCR-Erkennung für das Dokument gemacht wird und es somit nicht durchsuchbar ist. Leider sind allerdings nach meinen bisherigen Tests die OpenSource-OCR-Tools entweder nicht in der Lage den erkannten Text in die PDF einzusetzen und diese damit durchsuchbar zu machen oder aber sie liefern inakzeptable Resultate für Dokumente in deutscher Sprache.

Wie handhabt Ihr das? Hebt Ihr alles an Papier auf oder bevorzugt Ihr auch die digitale Archivierung? Wenn ja, welche Software nutzt Ihr?

* Natürlich werden die Dokumente dabei so aufbewahrt, dass ein Zugriff fremder Personen ohne ausdrückliche Einwilligung nicht möglich ist.

[HowTo] Selektive Privatsphäre im Facebook

Nachdem ich neulich gefragt wurde wie es geht verschiedenen Leuten verschiedene Berechtigungen im Facebook zuzuweisen möchte ich heute in einer kleinen Anleitung darauf eingehen, wie genau es gemacht wird. So kann dann z.B. den Kollegen vorenthalten werden, was man seinen Verwandten gerne zeigen möchte. Unliebsamen Personen, die man nur aus dem Grund als “Freund” hat, dass sie sonst so lange rumzetern würden, bis man sie doch akzeptiert, kann einfach fast alles vorenthalten werden.

Die eine Voraussetzung für dieses Vorhaben ist die Einteilung eurer Freunde in Listen. Die Berechtigungen können zwar auch einzelnen Personen zugeordnet werden, aber ich persönlich hätte bei dem komplizierten System bei Facebook keine große Lust für meine knapp 150 “Freunde” alles einzeln zu vergeben. Ansonsten wird noch ein gutes Stück Zeit benötigt um das Ganze sauber durchzuführen und nicht doch irgendwo ein unliebsames Schlupfloch zu lassen.

Personenorganisation

Fangen wir also mit den Listen an. Dazu klickt Ihr auf der Startseite vom Facebook in der linken Leiste auf den Reiter “Freunde”. Dann öffnet sich in der Mitte der schon bekannte “Finde deine Freunde” Krams. Zusätzlich gibt es oben rechts noch einen Button “Liste erstellen”. Sobald ihr diesen anklickt, öffnet sich ein kleines Fenster in der Facebook-Seite, welches euch auffordert eurer Liste einen Namen zu geben und dann eine Auswahl an Personen anzeigt, welche Ihr der Liste hinzufügen könnt:

Hier gebt Ihr den Namen der Liste (z.B. “Kollegen”) an und wählt dann in dem unteren Bereich mindestens eine Person aus. Wenn Ihr niemanden auswählt, wird die Liste nicht erzeugt. Nachdem Ihr also alle Leute in Listen organisiert habt (Eine Person kann durchaus auch in mehreren Listen sein!), geht es weiter zum nächsten Schritt.

Privatsphäre

An dieser Stelle benötigen wir den Menüpunkt aus dem Reiter “Konto” rechts oben in eurem Profil. Dieser Schritt wird definitiv am Längsten dauern, da mit den neuen Einstellungen im Facebook sehr viel feinere Optionen eingeführt wurden, die durchaus Sinn machen aber leider nicht mehr allzu einfach zu durchblicken sind.

Auf der Seite, die sich jetzt öffnet, sind vor allem die ersten drei Punkte “Profilinformationen”, “Kontaktinformationen” und “Anwendungen und Webseiten” wichtig.

Der einfachste dieser Punkte ist der Punkt “Anwendungen und Webseiten”. Diese Einstellungen dort im Punkt “Was deine Freunde über dich mit anderen teilen können” entscheiden, was eine Anwendung, die Ihr selber nicht nutzt, über euch erfährt wenn Freunde sie nutzen. Ich persönlich empfehle in diesem Punkt alle Haken zu entfernen! Ihr werdet es sicher schon festgestellt haben oder selbst so handhaben, dass viele Leute alle Anwendungen ausprobieren und im Nachhinein nicht einmal die Berechtigungen wieder entziehen. Somit haben diese Anwendungen auf Dauer Zugriff auf eure Profilinformationen.

Nachdem Ihr dieses “Leck” in der Sicherheitsinfrastruktur gestopft oder zumindest eingedämmt habt, wenden wir uns den “Kontaktinformationen” zu. Hier begegnen euch einige Felder, die eure gegebenen Informationen repräsentieren. Zum Beispiel haben wir da den Punkt “Handynummer”. Muss Kollege XYZ wirklich die private Handynummer kennen, nur weil wir im Gespräch an der Kaffeemaschine auf Facebook gestoßen sind und ihn deswegen als “Freund” hinzugefügt haben? Ich denke nicht.

Wenden wir uns also den Menüpunkten zu. Standardmäßig könnt Ihr zwischen “Alle” (wirklich alle im ganzen Facebook!), “Freunde von Freunden” (jeder kennt jeden über 3 Ecken oder so ähnlich), “Nur Freunde” (Alle Leute, die Ihr hinzugefügt habt) und “Benutzerdefiniert” wählen. Bei mir sind die Optionen “Webseite” und “Mich als FreundIn hinzufügen” für “Alle” freigegeben und der komplette Rest ist mit “Benutzerdefiniert” eingedämmt.

Die ersten drei Menüpunkte sind einfach. Wenn Ihr sie anklickt, werden sie direkt übernommen und gelten ab sofort. Nur der Punkt “Benutzerdefiniert”, der euch sicher interessiert, wenn Ihr meinen Artikel gerade lest, ist ein wenig schwieriger zu konfigurieren. Sehen wir uns das Fenster also ein wenig genauer an:

Oben könnt Ihr dabei einen Grundstock an Personen auswählen. Entweder nutzt Ihr dabei eine der vorgegebenen Kategorien wie z.B. “Nur Freunde” oder Ihr legt dort schon fest, dass Ihr nur bestimmte Personen erlauben wollt. Im unteren Bereich könnt Ihr dann noch bestimmte Listen ausschließen, die nichts sehen dürfen. In dem Screenshot hier seht Ihr meine Einstellungen für die Handynummer. Also mit anderen Worten: Meine Handynummer dürfen nur Personen der Liste “Approved” sehen. (Das ist bei mir eine Liste, der wenige Personen angehören und die wirklich alles sehen darf.)

Mit diesem Wissen könnt Ihr jetzt euer ganzes Profil entsprechend strukturieren, dass die Leute wirklich nur sehen dürfen, was sie sehen sollen. Die gleichen Optionen gelten auch im Bereich der Profilinformationen. Auch in den Fotoalben gibt es exakt die gleiche Einstellmöglichkeit. Nicht zu vergessen könnt Ihr auch für jedes Update, was Ihr schreibt noch einmal festlegen, wer es sehen darf. Zu den Einstellmöglichkeiten für die Fotoalben kommt Ihr im Übrigen über den Punkt “Profilinformationen” und dann “Fotoalben”.

Vorschau

Wenn Ihr dann so weit die Leute eingeteilt und ihnen Berechtigungen gegeben oder verwehrt habt, gibt es auf den Seiten “Profilinformationen” und “Kontaktinformationen” oben rechts den Button “Vorschau für mein Profil…”. Mit diesem könnt Ihr euer Profil so aufrufen wie eine beliebige Person es könnte. Standardmäßig wird euch die Ansicht für einen beliebigen Nutzer, der nicht euer Freund ist angezeigt. Wenn Ihr allerdings oben einen Namen in das entsprechende Feld eingebt, der auf einer eurer Listen steht, könnt Ihr euer Profil ansehen, wie der “Freund” es sehen würde.

So könnt Ihr so lange nachbessern, bis Ihr mit den Einstellungen zufrieden seid.

Meine Einteilung

Im Folgenden möchte ich euch meine Einteilung (natürlich ohne Personennamen) als Beispiel zeigen, wie es aussehen könnte. Kurz zu den verwendeten Zeichen: “=” bedeutet, dass die Optionen von dieser Gruppe übernommen werden. “-” bedeutet, dass diese Option für die Gruppe nicht sichtbar ist. “+” bedeutet, dass diese Gruppe die Berechtigung für die Option hat.

 * Approved
   * = Freunde
   * + Geburtstag
   * + Familie und Beziehung
   * + Handynummer
   * + Andere Telefonnummer
   * + Aktuelle Adresse
 * No Socialize
   * = Freunde
   * - Über mich
   * - Persönliches
   * - Rel. Ansichten & pol. Einstellung
   * - Ausbildung und Beruf
   * - Fotos und Videos von mir
   * - Beiträge von mir
   * - Beiträge von Freunden
   * - Kommentare zu Beiträgen
   * - IM-Nutzername
   * - Heimatstadt
 * Apps & Seiten
   * = No Socialize
 * Freunde
   * + Über mich
   * + Persönliches
   * - Geburtstag
   * + Rel. Ansichten & pol. Einstellung
   * - Familie und Beziehung
   * + Ausbildung und Beruf
   * + Fotos und Videos von mir
   * + Beiträge von mir
   * + Beiträge von Freunden
   * + Kommentare zu Beiträgen
   * + IM-Nutzername
   * - Handynummer
   * - Andere Telefonnummer
   * - Aktuelle Adresse
   * + Webseite
   * + Heimatstadt
   * + Mich als Freund hinzufügen
   * + Mir eine Nachricht schicken
   * + Mail-Adresse

*** Behandlung via "Freunde" ***
 * Ex-Kollegen
 * Ex-Mitschüler
 * Feuerwehr
 * Arbeit
 * Twitter
   * - Rel. Ansichten & pol. Einstellung

Ausgelassen habe ich hier die Berechtigungen für “Alle”, da ich sie oben im Text schon erwähnt hatte.

[Linux-Server] DKIM-Signaturen unter Ubuntu

E-Mail-Spam ist ein zeitfressendes Problem in unserer heutigen Gesellschaft und die Administratoren der Mailserver sind in einem permanenten Kopf-an-Kopf-Rennen mit den Versendern dieser unerwünschten und zeitraubenden E-Mails. Leider ist das ursprünglich genutzte SMTP-Protokoll selber nicht dafür ausgelegt Spam zu bekämpfen. Allerdings haben sich vor etwa 5 Jahren einige Leute bei Yahoo hingesetzt und eine DNS-basierte Signaturmöglichkeit für Mailserver erarbeitet. Inzwischen wurde die damals erarbeitete Lösung durch das neuere DKIM abgelöst.

DKIM arbeitet auf dem Prinzip der asymmetrischen Verschlüsselung und fügt der E-Mail serverseitig eine Signatur hinzu, die es ermöglicht zu prüfen, ob der Mailserver, der für die entsprechende Domain zuständig ist, auch wirklich der Versender der E-Mail ist. Somit kann kein anderer Server mehr behaupten, dass er im Auftrag des Domain-Eigentümers E-Mails versendet, obwohl er dazu nicht befugt ist, denn dann würde er die richtige Signatur setzen können. (Mehr Informationen zur Funktionsweise gibt es in der Wikipedia)

Zwar ist DKIM auch nicht die Lösung auf alle Spamprobleme, allerdings kann man sich je weiter sich DKIM durchsetzt, mehr auf die Resultate dieser Überprüfung verlassen und es wird schwerer für Spammer von Domains, die nicht ihnen selbst gehören, Spam zu versenden.

Im folgenden möchte ich die Einrichtung der DKIM-Signierung auf einem Ubuntu-Server zeigen. Ich setze dabei voraus, dass ein bereits vollständig laufender Postfix-Mailserver existiert. Weiterhin wird Zugriff auf das DNS benötigt, da einige Informationen im DNS abgelegt werden müssen. Alle hier aufgeführten Schritte und Befehle werden als Benutzer “root” durchgeführt.

Vorbereiten der Einrichtung

Im ersten Schritt wird das einzige zusätzlich notwendige Paket auf dem Ubuntu-Server installiert:

# aptitude install dkim-filter

Damit ist die Installation der neuen Pakete abgeschlossen und es kann mit der Konfiguration begonnen werden. Die Konfiguration besteht aus mehreren Schritten. Zuerst werden wir den DKIM-Deamon entsprechend einrichten, damit er die E-Mails signiert. Im zweiten Schritt binden wir den DKIM-Deamon in den schon bestehenden Postfix-Server ein. Der dritte Schritt dient der Konfiguration der Keys und des DNS.

Schritt 1: Konfiguration des DKIM-Deamon

Die Konfiguration besteht nach der Installation zuerst aus 2 Dateien. Die erste Datei befindet sich unter “/etc/defaults/dkim-filter” und legt fest, wie der DKIM-Deamon angesprochen werden kann. Hier sollte alles so gelassen werden wie es ist.

Die zweite Datei findet sich unter “/etc/dkim-filter.conf” und konfiguriert das eigentliche Verhalten des Servers. Hier werden wir einige Änderungen vornehmen. Hier als erstes eine Beispiel-Konfiguration, wie ich sie nutze:

# Log to syslog
Syslog			yes

# Weitere Domains mit Komma anfügen
Domain			example.com
# Standard-Selektor für die DNS-Abfrage
Selector		mail
KeyList			/etc/dkim-keys.conf

# Common settings. See dkim-filter.conf(5) for more information.
AutoRestart		yes
Background		yes
Canonicalization	simple
DNSTimeout		5
Mode			sv
SignatureAlgorithm	rsa-sha256
SubDomains		no
X-Header		no

# Standardaktionen bei bestimmten Vorkommnissen
On-Default              tempfail
On-BadSignature         tempfail
On-DNSError             tempfail
On-InternalError        accept
On-NoSignature          accept
On-Security             tempfail

Diese Konfiguration kann so übernommen werden und muss dann nur im Wert “Domain” angepasst werden. Dort müssen alle Domains aufgelistet werden, für die später eine Signatur gesetzt werden soll.

Weiterhin legen wir an dieser Stelle schon eine Datei und einen Ordner für die Verwendung in Schritt 3 an:

# touch /etc/dkim-keys.conf
# mkdir -p /etc/dkim/

Schritt 2: Einbinden in den Postfix-Mailserver

Die Einbindung in den Postfix-Server gestaltet sich recht einfach. Hierzu werden einfach folgende Zeilen in die Datei “/etc/postfix/main.cf” eingefügt: (Sollten schon vorher Milter konfiguriert gewesen sein, müssen die Zeilen entsprechend abgeändert werden!)

milter_default_action = accept
milter_protocol = 2
smtpd_milters = inet:localhost:8891
non_smtpd_milters = inet:localhost:8891

Wenn Ihr im ersten Schritt die Datei “/etc/defaults/dkim-filter” verändert habt, müssen diese Zeilen hier entsprechend angepasst werden.

Schritt 3: Konfiguration der Domains

Als erstes legen wir für die Schlüssel, die verwendet werden sollen, im Verzeichnis “/etc/dkim/” pro Domain einen Ordner an. Das ist deswegen nötig, da die Schlüssel für jede verwendete Domain immer exakt gleich benannt sein müssen wie der Selektor in der Konfiguration. Im Beispiel muss also der verwendete Schlüssel immer “mail” heißen.

mkdir -p /etc/dkim/example.com/

In diesem Ordner wird jetzt der Schlüssel für die Domain erzeugt:

# cd /etc/dkim/example.com/
# openssl genrsa -out mail 1024
# openssl rsa -in mail -out public.key -pubout -outform PEM

Damit ist die Erstellung der Keys abgeschlossen und wir können uns der Datei “/etc/dkim-keys.conf” zuwenden:

In dieser Datei wird pro Zeile ein Key der entsprechenden Domain zugeordnet, deren Mails mit diesem Key signiert werden sollen:

*@example.com:example.com:/etc/dkim/example.com/mail

Dabei ist schon zu sehen: Im ersten Feld werden die Absender-Adressen festgelegt, auf welche die Signierung angewandt werden soll. Im Normalfall dürften das alle Adressen sein. Das zweite Feld enthält die Signatur-Domain. Im dritten Feld steht der private Schlüssel der Domain zum Erzeugen der Signatur.

Nachdem diese Schritte abgeschlossen sind, geht es an die Konfiguration des DNS um den fremden Mailservern mitzuteilen, welchen Schlüssel wir verwenden und wie er mit den E-Mails verfahren soll. Dazu werden zwei TXT-DNS-Records angelegt:

1. Der DKIM-Eintrag:

mail._domainkey.example.com. IN TXT "v=DKIM1; g=*; k=rsa; p=[...];"

Hier muss das [...] durch den Public-Key in der Datei “/etc/dkim/example.com/public.key” ersetzt werden. Wenn also der Inhalt der “public.key“-Datei wie folgt aussieht:

-----BEGIN PUBLIC KEY-----
MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDgSDdeKxkVvr9myBLP66cMgLqb
0zy7kbV2UzuRVj99t2LiNEQg/l6P9Cgj1BWrVrkbMnKjCTNQbBnY8ASUFMx37EDc
Y1tpLshTMWcJ0piMNOPWyhpqe1QxbQYI2jLunxcgfHF4KjBAAZxI2Y0QHFCvlMdm
MYtpdq0G0MzBfqTTYwIDAQAB
-----END PUBLIC KEY-----

Dann muss der DNS-Eintrag etwa wie folgt aussehen:

mail._domainkey.example.com. IN TXT "v=DKIM1; g=*; k=rsa; p=MIGfMA...DAQAB;"

(Natürlich muss der komplette Key in den DNS-Eintrag eingetragen werden. Ich habe ihn nur der Übersichtlichkeit halber gekürzt.)

2. Der Policy-Eintrag:

_adsp._domainkey.example.com. IN TXT "dkim=all"

An dieser Stelle sind die Werte “unknown”, ”all” und “discardable” möglich. “unknown” bedeutet, dass nicht bekannt ist welche E-Mails signiert werden. Damit ist das auch die niedrigste Sicherheitsstufe. Bei “all” müssen alle E-Mails signiert sein, werden aber bei einem Fehlen der Signatur nicht abgelehnt sondern einfach nur als suspekt eingestuft. Der Wert “discardable” sagt aus, dass eine nicht signierte E-Mail abgewiesen werden darf.

Abschluss der Einrichtung

Zum Abschluss der Einrichtung werden auf dem Mailserver noch die Dienste “postfix” und “dkim-filter” neu gestartet, damit alle Änderungen übernommen werden:

# /etc/init.d/postfix restart
# /etc/init.d/dkim-filter restart

Damit ist die Einrichtung abgeschlossen und der folgende Test sollte erfolgreich verlaufen:

Zum Testen der Einrichtung kann eine E-Mail an den Autoresponder “autorespond+dkim@dk.elandsys.com” geschickt werden. Die Antwort auf diese E-Mail sollte dann folgenden Text enthalten:

DKIM Signature validation: pass (1048-bit key)
DKIM Author Domain Signing Practices: "dkim=all"

Wobei bei euch natürlich die ADSP-Anweisung anders aussehen kann. Sollten diese Informationen nicht zurück kommen, kann es sein, dass die DNS-Änderung noch nicht bekannt ist. Dann muss entsprechend der TTL der Zone gewartet werden, bis der Key und die ADSP bereit stehen. Ansonsten gibt der Autoresponder auch Informationen darüber aus, warum die Validierung nicht funktioniert hat.

Radiostreams mit wenig Bandbreite

Nachdem ich heute vor dem Problem stand einen Radio-Stream hören zu wollen, der mit 128kbit/s sendet, meine Leitung hier das aber nicht verträgt (ISDN) habe ich mal eine Möglichkeit gebastelt wie man das Problem umgehen kann. Diese Anleitung funktioniert natürlich auch, wenn Ihr z.B. euren Lieblingsstream unterwegs auf dem iPhone mit FStream über eine EDGE-Verbindung hören wollt. (Macht mit 128kbit auch keinen Spaß…)

Gleich vorweg: Diese Anleitung setzt im Endeffekt eine Kopie des originalen Streams auf. Ihr solltet das Ganze nur für euch persönlich aufsetzen. (Maximal noch eurem besten Freund erzählen.) Ich habe keine Ahnung wie das in Deutschland mit der Kopie eines Streams rechtlich ausschaut. Selbst wenn der eigentliche Streambesitzer nichts dagegen hat, könnten da gewisse staatliche Stellen so ihre Einwände haben. Solange Ihr das allerdings nur für euch persönlich baut sollte da nichts dagegen sprechen. (Hoffe ich…)

Die Anleitung ist im Übrigen für erfahrene Linux-Administratoren gedacht, da Software per Hand nachinstalliert werden muss. Solltet Ihr die entsprechende Erfahrung nicht haben, fragt bitte jemanden, der diese Ahnung hat.

Voraussetzungen

Fangen wir also mit dem benötigten “Material” an: Ihr braucht einen Server, der eine entsprechende Bandbreite (achtet auch auf den Traffic!) hat. Also z.B. eine günstige virtuelle Büchse in einem Rechenzentrum. Darauf sollte ein Ubuntu-System laufen. Wenn es ein Debian ist könnte die Anleitung auch noch 1:1 funktionieren.

Vorbereiten

Als ersten Schritt müssen wir auf dem Server einige Pakete installieren. Dazu wird der folgende Befehl ausgeführt:

aptitude install libogg-dev libvorbis-dev libmad0-dev libmp3lame-dev libflac-dev icecast2 build-essential

Damit wird einerseits der IceCast2-Server installiert, den wir später nutzen um den runtergerechneten Stream wieder zur Verfügung zu stellen. Andererseits legt der Befehl schon den Grundstein für die Installation vom Streamtranscoder. Den müssen wir auf Ubuntu leider manuell installieren, da es ihn nicht in der Paketverwaltung gibt.

Installieren vom Streamtranscoder

Im nächsten Schritt werden als root folgende Befehle ausgeführt:

cd ~
mkdir src
cd src
wget http://www.oddsock.org/tools/streamTranscoderV3/streamtranscoderv3-3.1.11.tar.gz
tar xzf streamtranscoderv3-3.1.11.tar.gz
cd streamtranscoderv3-3.1.11
./configure

Hierbei sollten bis jetzt keine Fehler auftreten. Falls doch fehlen wahrscheinlich Bibliotheken. Diese müsst Ihr dann über die Paketverwaltung nachinstallieren.

Der Streamtranscoderv3 wird dann über die Befehle

make
make install

installiert.

Konfigurieren des IceCast2

Die Dokumentation des IceCast2-Servers ist eigentlich relativ selbsterklärend. Daher gehe ich da nicht detailliert drauf ein. Wichtig ist, dass Ihr in der Datei “/etc/icecast2/icecast.xml” die Passwörter alle ändert. (Insgesamt 3 Stück). Außerdem müsst Ihr in der “/etc/default/icecast2” in der letzten Zeile den IceCast-Server aktivieren. Danach lässt sich der IceCast-Server starten und ist bereit unsere Streams aufzunehmen.

Konfigurieren des Streamtrancoderv3

Der Streamtranscoderv3 wartet leider schon seit 2007 auf eine sinnvolle Dokumentation, die es aber bisher noch nicht gibt. Daher hier kurz das Vorgehen, wie man ihn einrichtet: Als Erstes wechselt Ihr auf einen normalen Benutzer. Der Streamtranscoder sollte nicht als Root laufen!

Jetzt führt Ihr den Befehl “streamTranscoderv3” einmal aus. Dabei wird die Konfigurationsdatei “streamTranscoder_0.cfg” angelegt. In dieser Datei stellt Ihr den Quellstream ein und ändert ganz unten die Anzahl der Encoder auf mindestens 1.

Anschließend wird der Befehl “streamTranscoderv3” wieder aus. Jetzt wird die Konfigurationsdatei “streamTranscoder_1.cfg” automatisch erzeugt. In dieser Datei passt Ihr jetzt die Optionen für euren Stream an, wie er zum IceCast-Server gesendet werden soll. (Die Datei ist wieder selbsterklärend).

Streamtranscoder starten

Wenn Ihr beide Konfigurationen angepasst habt, könnt Ihr den Befehl “streamTranscoderv3” zum dritten Mal ausführen und damit den Streamtranscoder starten. Jetzt solltet Ihr mit einem beliebigen Client zu eurem IceCast-Server verbinden und die Musik anhören können.

Später könnt Ihr den Streamtranscoder mittels “streamTranscoderv3 -b” starten. Damit  legt er sich in den Hintergrund und Ihr könnt die Verbindung zum Server schließen.

HTTP-Authentifizierung in Ruby-Scripten auf dem Apache

HowTo

Dieser Artikel richtet sich an Programmierer, die mittels eines Ruby, Perl oder Python-Scripts in der CGI-Umgebung des Apache-Webservers eine Basic-Authentication durchführen möchten. Entsprechendes Vorwissen wird vorausgesetzt. Das Codebeispiel ist in Ruby gehalten.

Heute sah ich mich mit dem Problem konfrontiert, dass ich in einem Ruby-Script, welches in der CGI-Umgebung im Apache laufen soll eine Nutzer-Authentifizierung via HTTP (Die bekannten Passwortdialoge des Browsers selber) nutzen wollte. Dazu gab es zwar entsprechende Codeschnipsel, wie das funktionieren sollte, allerdings funktionierte keins davon.

Das Problem lag daran, dass der Apache-Server im Standardfall die Header, die für diese Authentifizierung benötigt werden nicht an die Scripte weiter gibt. Dazu gibt es dann die Möglichkeit Startparameter des Apache zu ändern, das CGI-Modul selber zu patchen oder aber die einfache Möglichkeit mit einer .htaccess-Datei.

Die ersten beiden Methoden fallen auf den meisten Webhostingpaketen flach (Mal abgesehen davon, dass kaum irgendwo Ruby unterstützt werden dürfte, das Problem existiert in Perl / Python als CGI ebenfalls.), da man keine Servereinstellungen ändern kann. Auch bei mir wollte ich an meiner normalen Konfiguration so wenig wie möglich ändern und habe somit zur dritten Möglichkeit gegriffen.

Um die fehlende Variable zur Verfügung zu stellen wird ein kleiner Zweizeiler als “.htaccess” im gleichen Verzeichnis wie das Script gespeichert:

RewriteEngine on
RewriteRule .* - [env=HTTP_AUTHORIZATION:%{HTTP:Authorization},last]

Das ist schon alles um die Variable hinzuzufügen.

Im Script selber wird das Auslesen der Variable dann schon ein wenig schwieriger. Das möchte ich hier auch nicht mehr ausführlich erklären sondern nur mit einem (eigentlich recht gut verständlichen Script) demonstrieren:

#!/usr/bin/ruby

require 'cgi'
require 'base64'

# Extend the CGI class with extractor for basic-auth credentials
class CGI
  # Passes back the credentials as array or nil when no credentials are provided
  def basic_auth_data
    if d = %w{REDIRECT_X_HTTP_AUTHORIZATION X-HTTP_AUTHORIZATION HTTP_AUTHORIZATION}.inject([]) \
    { |d,h| env_table.has_key?(h) and env_table[h].length > 0 ? env_table[h].to_s.split : d }
      return Base64.decode64(d[1]).split(':')[0..1] if d[0] == 'Basic'
    end
  end
end

# Here's an example usage:
cgi = CGI.new
username, password = cgi.basic_auth_data

# If there was no identification force the browser to ask for
puts cgi.header({
  "Status" => "401 Authorization Required",
  "Type" => "text/html",
  "WWW-Authenticate" => "Basic realm=\"My secret Area\""
}) if cgi.basic_auth_data.nil?

# Output control data
puts "Content-Type: text/plain"
puts

puts "Usr: '#{username}'"
puts "Pwd: '#{password}'"

Das Script findet sich mit Syntaxhighlighting und Downloadmöglichkeit auch noch im Nopaste.

knuttr2@knut.me