Der französische Anbieter gooze bietet die kostengünstigen und Open Source kompatiblen Smartcard Systeme des chinesischen Herstellers Feitian an. Die Smartcards und Tokens sind vergleichsweise preiswert und enthalten nicht die üblichen Abos, NDAs und andere Hürden, die einem bei anderen Anbietern für einen einfachen Einsatz im Weg stehen.
Darüberhinaus ist die Lieferung relativ schnell, wenn die Smartcards nicht irritierenderweise beim Zoll festsitzen oder die Lieferung aus China sich verspätet.
Das Token ePass2003 ist ein USB-Stick mit integrierter Smartcard und Kartenleser. Die Einrichtung des Tokens für die Verwendung mit opnevpn unter Mint 14 LMDE ist wird im Folgenden beschrieben.
Die aktuellen Debian Distributionen enthalten nicht die aktuellsten OpenSC Treiber. Auch wenn der Sicherheitsimpact abgewägt werden muss habe ich mich entscheiden das Repository von Gooze zu verwenden um passende und geprüfte OpenSC Pakete zu bekommen.
Um dies zu erreichen muss das Repository von Gooze der sources.list hinzugefügt werden. Da Mint 14 im Wesentlichen auf debian Wheezy basiert, wird das Wheezy Repo der sources.list hinzugefügt.
Als erstes müssen diese zwei Zeilen der Datei /etc/apt/sources.list hinzugefügt werden:
deb http://apt.gooze.eu/debian/ wheezy main
deb-src http://apt.gooze.eu/debian/ wheezy main
Mit:
# wget -q "http://apt.gooze.eu/257FF7B2.asc" -O- | sudo apt-key add -
wird der Schlüssel für die Gooze Packages dem Keyring hinzugefügt.
Im Ordner /etc/apt/preferences.d/ die Datei gooze mit folgendem Inhalt anlegen:
Package: *
Pin: origin o=apt.gooze.eu
Pin-Priority: 1001
Nach der Ausführung von apt-get update können alle notwendigen Pakete mit der Anweisung:
# apt-get install pcscd pcsc-tools libccid libpcsclite1 openvpn opensc/staging
installiert werden.
Das ePass2003 ist im Auslieferungszustand für die Feitian Windows-Treiber vorbereitet. Das verhindert die korrekte Erkennung unter Linux. Um das Token unter Linux "sichtbar" zu machen muss das Token neu initialisiert werden.
Während der Initialisierung werden die PIN und die PUK (SuperPIN) vereinbart, sowie ein Label, das verschiedene Programme bei der Nachfrage nach der PIN als Text verwenden.
$ pkcs15-init -E
$ pkcs15-init --create-pkcs15 --profile pkcs15+onepin \
--use-default-transport-key --pin 123456 \
--puk 7891011 --label "Peter
Mustermann"
Ist die Initialisierung erfolgreich sollte die Anweisung:
$ pkcs15-tool --dump
ungefähr die folgende Ausgabe liefern.
PKCS#15 Card [Peter Mustermann]:
Version : 0
Serial number : 1234567890091101
Manufacturer ID: EnterSafe
Last update : 20120630083313Z
Flags : EID compliant
PIN [User PIN]
Object Flags : [0x3], private, modifiable
ID : 01
Flags : [0x32], local, initialized, needs-padding
Length : min_len:4, max_len:16, stored_len:16
Pad char : 0x00
Reference : 1 (0x01)
Type : ascii-numeric
Path : 3f005015
...
Damit ist das Token betriebsbereit und kann mit Schlüsseln und Zertifikaten bespielt werden.
Wie man sich einen Schlüssel und ein Zertifikat für SSL erstellt ist erschöpfend im Netz beschrieben, weswegen ich diesen Punkt überspringe und davon ausgehe, das sich der Leser im Besitz einer gültigen PKCS#12 (.p12) Datei befindet.
Mit den Anweisungen:
$ openssl pkcs12 -in cert.p12 -clcerts -nokeys -out petercert.pem
$ openssl pkcs12 -in cert.p12 -cacerts -nokeys -out root.pem
$ openssl pkcs12 -in cert.p12 -nocerts -out peterkey.pem
werden die notwendigen Dateien aus der PKCS#12 Datei extrahiert.
Mit:
$ pkcs15-init --store-private-key peterkey.pem --auth-id 01 --pin 123456
wird der Schlüssel auf dem Token gespeichert. Während dieser Prozedur wird dem Schlüssel eine ID zugewiesen die ausgelesen werden muss, um das Zertifikat mit diesem Schlüssel zu assoziieren.
$ pkcs15-tool --list-keys
Listet alle Schlüssel des Tokens mit deren Ids:
Using reader with a card: Feitian ePass2003 00 00
Private RSA Key [Certificate]
Object Flags : [0x3], private, modifiable
Usage : [0x4], sign
Access Flags : [0xD], sensitive, alwaysSensitive, neverExtrac
ModLength : 2048
Key ref : 0 (0x0)
Native : yes
Path : 3f0050152900
Auth ID : 01
ID : 012347050ef750567872b7e7aa80539110b0e921
GUID : {0abc494d-2712-32dc-b64d-be218b23ce90}
Die ID muss beim Speichern des Zertifikates angegeben werde:
# pkcs15-init --store-certificate petercert.pem --auth-id 01 \
--id 012347050ef750567872b7e7aa80539110b0e921 --format pem
Das Token ist jetzt vollständig eingerichtet.
Um das Token für openvpn nutzbar zu machen muss eine Client Konfiguration im Ordner /etc/openvpn angelegt werden. Openvpn erzeugt seine eigenen IDs mit denen es Schlüssel auf dem Token identifiziert. Diese ID wird mit:
# openvpn --show-pkcs11-ids /usr/lib/opensc-pkcs11.so
ausgelesen und sieht ungefähr so aus:
The following objects are available for use.
Each object shown below may be used as parameter to
--pkcs11-id option please remember to use single quote mark.
Certificate
DN: /C=DE/ST=Berlin/L=Berlin/O=Foobar GmbH/OU=FooSecurity/CN=Peter Mustermann
Serial: 09
Serialized id: EnterSafe/PKCS\x2315/6257011116091101/Peter\x20Mustermann\x20\x28User\x20PIN\x29/0012347050ef750567872b7e7aa80539110b0e9211
Der gelb markierte Hinweis ist unbedingt zu beachten, da ansonsten die \ Zeichen falsch interpretiert und das Zeritifkat nicht mehr zugeordnet werden kann.
Eine minimale /etc/openvpn/client.conf könnte dann so aussehen, wobei hierzu unbedingt die Dokumentation der OpenVPN Website konsultiert werden sollte.
Außerdem hängt der Inhalt der Datei von den Einstellungen ab, die auf der Serverseite durchgeführt worden sind. Für einen einfachen minimalen Test reicht das angegebene Beispiel in jedoch aus.
client
dev tun
proto udp
remote vpn.foobar.com
nobind
persist-key
persist-tun
ca /etc/openvpn/certs/foobar-ca.cert
pkcs11-providers /usr/lib/opensc-pkcs11.so
pkcs11-id 'EnterSafe/PKCS\x2315/6257011116091101/Peter\x20Mustermann\x20\x28User\x20PIN\x29/0012347050ef750567872b7e7aa80539110b0e9211'
comp-lzo
Mit der Anweisung:
# openvpn --config /etc/openvpn/vpn.sourcepark.biz --verb 2
beginnt der Aufbau der Tunnelverbindung. Sobald der Server kontaktiert wurde und der SSL Handshake begonnen hat wird die PIN abgefragt. Nach Eingabe der korrekten PIN wird die Tunnelverbindung etabliert und kann verwendet werden.
Das Erstellen der Zertifikate und die korrekte Verwendung verlangen etwas Übung. Sollte das Token nicht wie gewünscht arbeiten, kann man den Tunnel testweise nur mit den Zertifikaten aufbauen, und anschlie0end die geprüften Zertifkate auf das Token übertragen.
Eine OpenVPN Client Konfiguration, die mit der Zertifkats- und Schlüsseldatei arbeitet würde so aussehen:
client
dev tun
proto udp
remote vpn.foobar.com
nobind
persist-key
persist-tun
ca /etc/openvpn/certs/foobar-ca.cert
cert /etc/openvpn/certs/petercert.pem
key /etc/openvpn/private/peterkey.pem
comp-lzo
Kann mit dieser Konfiguration kein Tunnel etabliert werden liegt es an den Zertifikaten. Lässt sich mit der Angegebenen Konfiguration ein Tunnel aufbauen, arbeitet der Treiber oder das Token nicht korrekt.
Dienstag, 2. Juli 2013
Samstag, 27. April 2013
Sennheiser MM 450-X unter Mint 14 LMDE einbinden
Mit dem Bluetooth Headset unter Linux Musik hören ist leider immer noch ein wenig schwierig. Die meisten Headsets werden nach dem Pairing in der Ansicht der verfügbaren Audiohardware gelistet, aber das klappt leider nicht immer.
Für alle bei denen das nicht funktioniert hat, hier eine kurze Beschreibung wie ich mein Sennheiser MM 450-X Headset unter Mint 14 LMDE installiert habe.
Das Headset ließ sich nur mit dem Rechner verbinden, wenn man im Bluetoot Pairing Dialog den Typ auf "Alle Typen" stellt. Das Pairing ist problemlos und das Device erschient in der Liste der bekannten Geräte.
Als Wiedergabegerät lässt es sich jedoch noch nicht verwenden. Das Paket bluez-alsa muss installiert werden um Bluetooth Audio Geräte für Alsa verfügbar zu machen.
apt-get install bluez-alsa
Damit das Headset auch unter einem bestimmten Namen als Gerät verwendet werden muss eine .asound Datei im Homeverzeichnis angelegt werden.
pcm.btheadset {
type plug
slave {
pcm {
type bluetooth
device 00:16:94:0B:97:F6
profile "auto"
}
}
hint {
show on
description "Sennheiser MX-450"
}
}
ctl.btheadset {
type bluetooth
}
Abmelden und wieder anmelden oder besser den Rechner neu starten.
Mit dem Kommando:
mplayer -ao alsa:device=btheadset <Eine MP3 Datei>
kann geprüft werden, ob das Headset schon funktioniert.
Sollte kein Audio über das Headset wiedergegeben werden und die Ausgabe von mplayer ungefähr so aussehen:
Selected audio codec: [mpg123] afm: mpg123 (MPEG 1.0/2.0/2.5 layers I, II, III)
==========================================================================bt_audio_service_open: connect() failed: Connection refused (111)
[AO_ALSA] Playback open error: Connection refused
Failed to initialize audio driver 'alsa:device=btheadset'
Could not open/initialize audio device -> no sound.
Audio: no sound
Video: no video
muss in die Datei /etc/bluetooth/audio.conf in der Sektion [General] die Zeile:
Enable=Socket
hinzugefügt werden. Anschließend muss der Bluetooth Dienst mit /etc/init.d/bluetooth restart neu gestartet werden.
Ein erneuter Start des mplayers sollte jetzt die Tonwiedergabe über das Headset lenken.
Der letzte Schritt zu einer vollständigen Integration in den Desktop, ist die installation des pulseaudio bluetooth Moduls und von pavucontrol mit:
apt-get install pulseaudio-module-bluetooth pavucontrol
Anschließend den pulsaudio Daemon mit pulseaudio -k neu starten.
Unter Mint 14 LMDE hat das Bluetooth Tray Icon in meiner Installation einen Fehler. Wähle ich aus dem Pop-Up Menü des Try-Icons das Headset aus und wähle verbinden, wird keine Verbindung zum Headset hergestellt.
Wähle ich aus dem Pop-Up Menü den Menüpunkt Bluetooth Einstellungen und verbinde das Headset dort wird die Verbindung korrekt hergestellt.
Das Headset sollte jetzt als Audiohardware in pavucontrol angezeigt werden.
Sollte die Tonqualität an ein Handygespräch erinnern, muss im Konfigurations-Tab von pavucontrol das Profil A2DP ausgewählt werden.
Für alle bei denen das nicht funktioniert hat, hier eine kurze Beschreibung wie ich mein Sennheiser MM 450-X Headset unter Mint 14 LMDE installiert habe.
Das Headset ließ sich nur mit dem Rechner verbinden, wenn man im Bluetoot Pairing Dialog den Typ auf "Alle Typen" stellt. Das Pairing ist problemlos und das Device erschient in der Liste der bekannten Geräte.
Als Wiedergabegerät lässt es sich jedoch noch nicht verwenden. Das Paket bluez-alsa muss installiert werden um Bluetooth Audio Geräte für Alsa verfügbar zu machen.
apt-get install bluez-alsa
Damit das Headset auch unter einem bestimmten Namen als Gerät verwendet werden muss eine .asound Datei im Homeverzeichnis angelegt werden.
pcm.btheadset {
type plug
slave {
pcm {
type bluetooth
device 00:16:94:0B:97:F6
profile "auto"
}
}
hint {
show on
description "Sennheiser MX-450"
}
}
ctl.btheadset {
type bluetooth
}
Abmelden und wieder anmelden oder besser den Rechner neu starten.
Mit dem Kommando:
mplayer -ao alsa:device=btheadset <Eine MP3 Datei>
kann geprüft werden, ob das Headset schon funktioniert.
Sollte kein Audio über das Headset wiedergegeben werden und die Ausgabe von mplayer ungefähr so aussehen:
Selected audio codec: [mpg123] afm: mpg123 (MPEG 1.0/2.0/2.5 layers I, II, III)
==========================================================================bt_audio_service_open: connect() failed: Connection refused (111)
[AO_ALSA] Playback open error: Connection refused
Failed to initialize audio driver 'alsa:device=btheadset'
Could not open/initialize audio device -> no sound.
Audio: no sound
Video: no video
muss in die Datei /etc/bluetooth/audio.conf in der Sektion [General] die Zeile:
Enable=Socket
hinzugefügt werden. Anschließend muss der Bluetooth Dienst mit /etc/init.d/bluetooth restart neu gestartet werden.
Ein erneuter Start des mplayers sollte jetzt die Tonwiedergabe über das Headset lenken.
Der letzte Schritt zu einer vollständigen Integration in den Desktop, ist die installation des pulseaudio bluetooth Moduls und von pavucontrol mit:
apt-get install pulseaudio-module-bluetooth pavucontrol
Anschließend den pulsaudio Daemon mit pulseaudio -k neu starten.
Unter Mint 14 LMDE hat das Bluetooth Tray Icon in meiner Installation einen Fehler. Wähle ich aus dem Pop-Up Menü des Try-Icons das Headset aus und wähle verbinden, wird keine Verbindung zum Headset hergestellt.
Wähle ich aus dem Pop-Up Menü den Menüpunkt Bluetooth Einstellungen und verbinde das Headset dort wird die Verbindung korrekt hergestellt.
Das Headset sollte jetzt als Audiohardware in pavucontrol angezeigt werden.
Sollte die Tonqualität an ein Handygespräch erinnern, muss im Konfigurations-Tab von pavucontrol das Profil A2DP ausgewählt werden.
Montag, 31. Dezember 2012
Raspberry Audio ohne Störungen
Der Rapberry PI ist mit 30-40 € sicher eines der günstigsten LINUX basierten Einplatinensysteme die im Augenblick auf dem Markt verfügbar sind.
Die Verwendung als Low-Cost Audiowiedergabestation drängt sich förmlich auf.
Leider haben die aktuellen Versionen einen Bug im Audiosystem, der dazu führt, dass am Ende der Wiedergabe einer MP3 Datei ein häßliches PLOP oder POP Geräusch zu hören ist.
Dieser Artikel beschreibt eine einfach Möglichkeit diese Störungen weitgehend zu unterdrücken.
Die Störung scheint zu entstehen, wenn der Raspberry das Audiodevice bzw. den entsprechenden Treiber öffnet oder schließt. Wird mit mplayer, vlc oder gst123 eine Playliste wiedergegeben ertönt das Knacken nach und for jedem einzelnen MP3.
Ein Blick in die Suchmaschine ergab, dass das Problem bekannt, eine Behebung aber im Augenblick nicht verfügbar und unter Umständen nur durch einen Hardwareupgrade zu beheben ist.
Hier mein Vorschlag für einen Workaround:
mit
apt-get install pulseaudio
den pulseaudio Server installieren.
Nach erfolgreicher Installation in der Datei /etc/default/pulseaudio die Zeile:
PULSEAUDIO_SYSTEM_START=0
in
PULSEAUDIO_SYSTEM_START=1
ändern.
Diese Änderung sorgt dafür, dass der pulseaudio Server direkt beim Systemstart ausgeführt wird. Der pulseaudio Server öffnet das Audiodevice und das Störgeräusch wird einmal beim Booten wiedergegeben.
Damit alle Programme, die ALSA verwenden auf den pulseaudio Server umgelenkt werden muss die Datei /etc/asound.conf angepasst werden.
Die original asound.conf sichern. Anschließend die folgenden Zeilen in die Datei /etc/asound.conf eintragen:
pcm.pulse {
type pulse
}
ctl.pulse {
type pulse
}
pcm.!default {
type pulse
}
ctl.!default {
type pulse
}
Der pulseaudio Server schließt nicht verwendete Audiogeräte nach einer gewissen Zeit. Da dies ebenfalls das Störgeräusch erzeugt findet, man gelegentlich den Hinweis die folgende Änderung in der Datei /etc/pulse/system.pa durchzuführen. Änderung von:
load-module module-suspend-on-idle
in
#load-module module-suspend-on-idle
Mein Raspberry gibt nach dieser Änderung keinen Ton mehr von sich. Ich rate also davon ab diese Änderung durchzuführen.
Wer die Wiedergabelautstärke seines Raspberry remote steuern möchte kann die folgende Zeile an die Datei /etc/pulse/system.pa anhängen.
load-module module-native-protocol-tcp auth-ip-acl=127.0.0.1;192.168.1.0/24 listen="0.0.0.0"
Bei dieser Änderung bitte die berechtigten Subnetze anpassen. Also für ein typisches fritzbox Netz wurde statt: 192.168.1.0/24 in 192.168.178.0/24 geändert werden.
Durch diese Änderung wird der pulseaudio Server über die Netzwerkschnittstelle erreichbar. Soll die Lautstärke von einem anderen Rechner aus geändert werden, muss die Umgebungsvariable PULSE_SERVER die IP Adresse des Raspberry enthalten. Nach dem Setzen der Variable kann man GUI Tools wie pavucontrol oder pacmd verwenden, um die Lautstärke zu ändern.
Bei pactl muss der Server direkt über die -s Option angegeben werden.
Beispiele:
$ pactl -s <raspberry IP> set-sink-volume 0 50000
$ PULSE_SERVER=<raspberrypi IP> pavucontrol
Als letzter Schritt müssen alle Benutzer, die Audio wiedergeben möchten den Gruppen pulse und pulse-access zugefügt werden, andernfalls erscheint die folgende Fehlermeldung:
[AO_ALSA] alsa-lib: pulse.c:243:(pulse_connect) PulseAudio: Unable to connect: Access denied
Also für jeden Benutzer der Audio wiedergeben können soll, müssen die beiden Befehle als root oder mit sudo ausgeführt werden:
# addgroup pi pulse
# addgroup pi pulse-access
Sind alle Änderungen durchgeführt, den Raspberry neu starten. Das Problem mit dem Plop sollte jetzt nur noch beim Starten oder Stoppen auftreten, bzw. wenn der pulseaudio Server das Device öffnet oder schließt. Zwischen den MP3s sollte es zumindest deutlich leiser, wenn nicht ganz verschwunden sein.
EDIT:
Eine weitere Quelle für verbrummtes oder anderweitig gestörtes Audio kann auch das Netzteil und das verwendete Kabel sein. Sitzt die Masse des Steckers locker im Netzteil kann das zu erheblichen Störungen führen. Auch preiswerte USB-Netzteil oder billige Kabel können zu Störungen bei der Audiowiedergabe führen.
Bei Problemen einfach mal Kabel und/Oder Netzteil tauschen.
Die Verwendung als Low-Cost Audiowiedergabestation drängt sich förmlich auf.
Leider haben die aktuellen Versionen einen Bug im Audiosystem, der dazu führt, dass am Ende der Wiedergabe einer MP3 Datei ein häßliches PLOP oder POP Geräusch zu hören ist.
Dieser Artikel beschreibt eine einfach Möglichkeit diese Störungen weitgehend zu unterdrücken.
Die Störung scheint zu entstehen, wenn der Raspberry das Audiodevice bzw. den entsprechenden Treiber öffnet oder schließt. Wird mit mplayer, vlc oder gst123 eine Playliste wiedergegeben ertönt das Knacken nach und for jedem einzelnen MP3.
Ein Blick in die Suchmaschine ergab, dass das Problem bekannt, eine Behebung aber im Augenblick nicht verfügbar und unter Umständen nur durch einen Hardwareupgrade zu beheben ist.
Hier mein Vorschlag für einen Workaround:
mit
apt-get install pulseaudio
den pulseaudio Server installieren.
Nach erfolgreicher Installation in der Datei /etc/default/pulseaudio die Zeile:
PULSEAUDIO_SYSTEM_START=0
in
PULSEAUDIO_SYSTEM_START=1
ändern.
Diese Änderung sorgt dafür, dass der pulseaudio Server direkt beim Systemstart ausgeführt wird. Der pulseaudio Server öffnet das Audiodevice und das Störgeräusch wird einmal beim Booten wiedergegeben.
Damit alle Programme, die ALSA verwenden auf den pulseaudio Server umgelenkt werden muss die Datei /etc/asound.conf angepasst werden.
Die original asound.conf sichern. Anschließend die folgenden Zeilen in die Datei /etc/asound.conf eintragen:
pcm.pulse {
type pulse
}
ctl.pulse {
type pulse
}
pcm.!default {
type pulse
}
ctl.!default {
type pulse
}
Der pulseaudio Server schließt nicht verwendete Audiogeräte nach einer gewissen Zeit. Da dies ebenfalls das Störgeräusch erzeugt findet, man gelegentlich den Hinweis die folgende Änderung in der Datei /etc/pulse/system.pa durchzuführen. Änderung von:
load-module module-suspend-on-idle
in
#load-module module-suspend-on-idle
Mein Raspberry gibt nach dieser Änderung keinen Ton mehr von sich. Ich rate also davon ab diese Änderung durchzuführen.
Wer die Wiedergabelautstärke seines Raspberry remote steuern möchte kann die folgende Zeile an die Datei /etc/pulse/system.pa anhängen.
load-module module-native-protocol-tcp auth-ip-acl=127.0.0.1;192.168.1.0/24 listen="0.0.0.0"
Bei dieser Änderung bitte die berechtigten Subnetze anpassen. Also für ein typisches fritzbox Netz wurde statt: 192.168.1.0/24 in 192.168.178.0/24 geändert werden.
Durch diese Änderung wird der pulseaudio Server über die Netzwerkschnittstelle erreichbar. Soll die Lautstärke von einem anderen Rechner aus geändert werden, muss die Umgebungsvariable PULSE_SERVER die IP Adresse des Raspberry enthalten. Nach dem Setzen der Variable kann man GUI Tools wie pavucontrol oder pacmd verwenden, um die Lautstärke zu ändern.
Bei pactl muss der Server direkt über die -s Option angegeben werden.
Beispiele:
$ pactl -s <raspberry IP> set-sink-volume 0 50000
$ PULSE_SERVER=<raspberrypi IP> pavucontrol
Als letzter Schritt müssen alle Benutzer, die Audio wiedergeben möchten den Gruppen pulse und pulse-access zugefügt werden, andernfalls erscheint die folgende Fehlermeldung:
[AO_ALSA] alsa-lib: pulse.c:243:(pulse_connect) PulseAudio: Unable to connect: Access denied
Also für jeden Benutzer der Audio wiedergeben können soll, müssen die beiden Befehle als root oder mit sudo ausgeführt werden:
# addgroup pi pulse
# addgroup pi pulse-access
Sind alle Änderungen durchgeführt, den Raspberry neu starten. Das Problem mit dem Plop sollte jetzt nur noch beim Starten oder Stoppen auftreten, bzw. wenn der pulseaudio Server das Device öffnet oder schließt. Zwischen den MP3s sollte es zumindest deutlich leiser, wenn nicht ganz verschwunden sein.
EDIT:
Eine weitere Quelle für verbrummtes oder anderweitig gestörtes Audio kann auch das Netzteil und das verwendete Kabel sein. Sitzt die Masse des Steckers locker im Netzteil kann das zu erheblichen Störungen führen. Auch preiswerte USB-Netzteil oder billige Kabel können zu Störungen bei der Audiowiedergabe führen.
Bei Problemen einfach mal Kabel und/Oder Netzteil tauschen.
Donnerstag, 11. Oktober 2012
Grails WAR mit Maven auf einen entfernten Tomcat deployen
Zum kompilieren einer Grails Applikation wird das Grails Plugin verwendet. Das produzierte Artefakt kann dann durch Verwendung des Cargo Maven Plugins auf einen entfernten Tomcat Server, in meinem Fall einem Tomcat 6, deployed werden.
Mit root Berechtigung reicht die Ausführung des Kommandos:
apt-get install tomcat6 tomcat6-admin
um alles notwendige zu installieren.
Anschließend muss ein Tomcat-Benutzer eingerichtet werden. Die Datei /var/lib/tomcat6/conf/tomcat-users.xml muss um die folgenden Einträge erweitert werden:
<role rolename="manager-gui"/>
<role rolename="manager-script"/>
<role rolename="manager-jmx"/>
<role rolename="manager-status"/>
<user username="me" password="secret"
roles="manager-gui,manager-script,manager-jmx,manager-status"/>
Diese Erweiterung sorgt dafür, dass der Benutzer "me" mit dem Passwort "secret" Zugriff auf die Managementfunktionen des Tomcat bekommt.
Beim Deployment von Grails Applikationen kommt es häufig zu einem "out of PermGenSpace" Fehler. Um diesen zu vermeiden sollte die JAVA_OPTS Zeile in der Datei /etc/default/tomcat6 um die Option -XX:MaxPermSize=256m erweitert werden. Dadurch wird der PermGenSpace auf 256 MByte vergrößert und reicht in den meisten Fällen aus.
Die JAVA_OPTS Zeile in /etc/default/tomcat6 sollte dann so aussehen:
...
JAVA_OPTS="-Djava.awt.headless=true -Xmx128m -XX:+UseConcMarkSweepGC
-XX:MaxPermSize=256m"
...
Damit sind alle für Tomcat notwendigen Einstellungen vorgenommen und Tomcat muss mit:
/etc/init.d/tomcat6 restart
neu gestartet werden, damit alle durchgeführten Änderungen wirksam werden.
Beispiel:
<plugin>
<groupId>org.codehaus.cargo</groupId>
<artifactId>cargo-maven2-plugin</artifactId>
<version>1.0.6</version>
<configuration>
<container>
<containerId>tomcat6x</containerId>
<type>remote</type>
</container>
<configuration>
<type>runtime</type>
<properties>
<cargo.tomcat.manager.url>
http://myserver:8080/manager
</cargo.tomcat.manager.url>
<cargo.remote.username>me</cargo.remote.username>
<cargo.remote.password>secret</cargo.remote.password>
</properties>
</configuration>
<deployer>
<type>remote</type>
<deployables>
<deployable>
<location>target/${artifactId}-${version}.war</location>
<groupId>${groupId}</groupId>
<artifactId>${artifactId}</artifactId>
<type>war</type>
<properties>
<context>${artifactId}</context>
</properties>
</deployable>
</deployables>
</deployer>
</configuration>
</plugin>
Das <location> Tag sorgt dafür, dass das gerade erstellte Artefakt über das Filesystem und nicht aus dem Build selbst heraus deployed wird.
Da das Grails Plugin den Packaging-Type grails-app benötigt, das Cargo Plugin aber nur Standard Packaging Types wie war, ear usw. verarbeitet, würde es sonst zu folgendem Fehler kommen:
[INFO] [cargo:redeploy {execution: default-cli}]
[WARNING] The defined deployable has the same groupId and artifactId
as your project's main artifact but the type is different. You've
defined a [war] type whereas the project's packaging is
[grails-app]. This is possibly an error and as a consequence the
plugin will try to find this deployable in the project's
dependencies.
[INFO] ----------------------------------------------------------------------
[ERROR] BUILD ERROR
Wenn der POM angepasst wurde und alles korrekt konfiguriert worden ist, kann mit dem Kommando:
mvn -Dmaven.test.skip=true clean install cargo:redeploy
das Artefakt gebaut und deployed werden.
Tomcat Einstellungen
Ich verwende Tomcat aus dem stable Repository von Debian Squeeze. Um später das Remote-Deployment durchführen zu können muss zusätzlich zum Package tomcat6 das Package tomcat6-admin installiert sein.Mit root Berechtigung reicht die Ausführung des Kommandos:
apt-get install tomcat6 tomcat6-admin
um alles notwendige zu installieren.
Anschließend muss ein Tomcat-Benutzer eingerichtet werden. Die Datei /var/lib/tomcat6/conf/tomcat-users.xml muss um die folgenden Einträge erweitert werden:
<role rolename="manager-gui"/>
<role rolename="manager-script"/>
<role rolename="manager-jmx"/>
<role rolename="manager-status"/>
<user username="me" password="secret"
roles="manager-gui,manager-script,manager-jmx,manager-status"/>
Diese Erweiterung sorgt dafür, dass der Benutzer "me" mit dem Passwort "secret" Zugriff auf die Managementfunktionen des Tomcat bekommt.
Beim Deployment von Grails Applikationen kommt es häufig zu einem "out of PermGenSpace" Fehler. Um diesen zu vermeiden sollte die JAVA_OPTS Zeile in der Datei /etc/default/tomcat6 um die Option -XX:MaxPermSize=256m erweitert werden. Dadurch wird der PermGenSpace auf 256 MByte vergrößert und reicht in den meisten Fällen aus.
Die JAVA_OPTS Zeile in /etc/default/tomcat6 sollte dann so aussehen:
...
JAVA_OPTS="-Djava.awt.headless=true -Xmx128m -XX:+UseConcMarkSweepGC
-XX:MaxPermSize=256m"
...
Damit sind alle für Tomcat notwendigen Einstellungen vorgenommen und Tomcat muss mit:
/etc/init.d/tomcat6 restart
neu gestartet werden, damit alle durchgeführten Änderungen wirksam werden.
MAVEN Einstellungen
In der pom.xml der Grails-Applikation wird das Cargo Plugin hinzugefügt. In der Plugin Konfiguration werden alle relevanten Daten wie der Server auf dem Deployed werden soll, sowie die oben festgelegten Zugangsdaten konfiguriert.Beispiel:
<plugin>
<groupId>org.codehaus.cargo</groupId>
<artifactId>cargo-maven2-plugin</artifactId>
<version>1.0.6</version>
<configuration>
<container>
<containerId>tomcat6x</containerId>
<type>remote</type>
</container>
<configuration>
<type>runtime</type>
<properties>
<cargo.tomcat.manager.url>
http://myserver:8080/manager
</cargo.tomcat.manager.url>
<cargo.remote.username>me</cargo.remote.username>
<cargo.remote.password>secret</cargo.remote.password>
</properties>
</configuration>
<deployer>
<type>remote</type>
<deployables>
<deployable>
<location>target/${artifactId}-${version}.war</location>
<groupId>${groupId}</groupId>
<artifactId>${artifactId}</artifactId>
<type>war</type>
<properties>
<context>${artifactId}</context>
</properties>
</deployable>
</deployables>
</deployer>
</configuration>
</plugin>
Das <location> Tag sorgt dafür, dass das gerade erstellte Artefakt über das Filesystem und nicht aus dem Build selbst heraus deployed wird.
Da das Grails Plugin den Packaging-Type grails-app benötigt, das Cargo Plugin aber nur Standard Packaging Types wie war, ear usw. verarbeitet, würde es sonst zu folgendem Fehler kommen:
[INFO] [cargo:redeploy {execution: default-cli}]
[WARNING] The defined deployable has the same groupId and artifactId
as your project's main artifact but the type is different. You've
defined a [war] type whereas the project's packaging is
[grails-app]. This is possibly an error and as a consequence the
plugin will try to find this deployable in the project's
dependencies.
[INFO] ----------------------------------------------------------------------
[ERROR] BUILD ERROR
Wenn der POM angepasst wurde und alles korrekt konfiguriert worden ist, kann mit dem Kommando:
mvn -Dmaven.test.skip=true clean install cargo:redeploy
das Artefakt gebaut und deployed werden.
Dienstag, 4. September 2012
Zotac Box mit HDMI Audio
HDMI Audio ist unter Linux und speziell unter Debian immer ein wenig kompliziert in Betrieb zu nehmen.
Ich beschreibe hier kurz wie ich meine Zotac Box, die mit einem NVIDIA Ion Chipset ausgerüstet ist eingerichtet habe. Auf der Box läuft ein Debian Squeeze (6.0.3) und MythTV 0.24.
Das alsa Package und das alsa-utils Package müssen installiert sein.
Mit aplay -l werden alle Audiodevices aufgelistet. Das sieht bei mir so aus:
root@twinpeaks:~# aplay -l
**** Liste der Hardware-Geräte (PLAYBACK) ****
Karte 0: Intel [HDA Intel], Gerät 0: ALC888 Analog [ALC888 Analog]
Sub-Geräte: 1/1
Sub-Gerät #0: subdevice #0
Karte 0: Intel [HDA Intel], Gerät 1: ALC888 Digital [ALC888 Digital]
Sub-Geräte: 1/1
Sub-Gerät #0: subdevice #0
Karte 1: NVidia [HDA NVidia], Gerät 3: HDMI 0 [HDMI 0]
Sub-Geräte: 1/1
Sub-Gerät #0: subdevice #0
Karte 1: NVidia [HDA NVidia], Gerät 7: HDMI 0 [HDMI 0]
Sub-Geräte: 1/1
Sub-Gerät #0: subdevice #0
Karte 1: NVidia [HDA NVidia], Gerät 8: HDMI 0 [HDMI 0]
Sub-Geräte: 1/1
Sub-Gerät #0: subdevice #0
Karte 1: NVidia [HDA NVidia], Gerät 9: HDMI 0 [HDMI 0]
Sub-Geräte: 1/1
Sub-Gerät #0: subdevice #0
Welches der vielen Audiodevices das Richtige ist habe ich durch probieren ermittelt. Hierzu eigenet sich das in den alsa-utils enthaltene speaker-test Programm.
HDMI Kabel an den Fernseher anschließen. Lautstärke des Fernsehers beachten, also nicht zu niedrig einstellen.
Anschließend für jedes der aufgelisteten Geräte das Kommando:
speaker-test -Dplughw:<Karte>,<Gerät>
ausführen. Wobei <Karte> durch die Nummer der Karte und <Gerät> durch die Nummer des Gerätes ersetzt werden müssen. Also das Kommando um das erste Gerät der Liste zu testen wäre dann:
speaker-test -Dplughw:0,0
Bei mir war es plughw:1,7. Hat man das Device identifiziert kann man es als Alsa Default Device vereinbaren, in dem man die Datei /etc/asound.conf wir folgt anlegt:
pcm.!default {
type plug
slave.pcm {
type hw
card 1
device 7
}
}
Ich beschreibe hier kurz wie ich meine Zotac Box, die mit einem NVIDIA Ion Chipset ausgerüstet ist eingerichtet habe. Auf der Box läuft ein Debian Squeeze (6.0.3) und MythTV 0.24.
Das alsa Package und das alsa-utils Package müssen installiert sein.
Mit aplay -l werden alle Audiodevices aufgelistet. Das sieht bei mir so aus:
root@twinpeaks:~# aplay -l
**** Liste der Hardware-Geräte (PLAYBACK) ****
Karte 0: Intel [HDA Intel], Gerät 0: ALC888 Analog [ALC888 Analog]
Sub-Geräte: 1/1
Sub-Gerät #0: subdevice #0
Karte 0: Intel [HDA Intel], Gerät 1: ALC888 Digital [ALC888 Digital]
Sub-Geräte: 1/1
Sub-Gerät #0: subdevice #0
Karte 1: NVidia [HDA NVidia], Gerät 3: HDMI 0 [HDMI 0]
Sub-Geräte: 1/1
Sub-Gerät #0: subdevice #0
Karte 1: NVidia [HDA NVidia], Gerät 7: HDMI 0 [HDMI 0]
Sub-Geräte: 1/1
Sub-Gerät #0: subdevice #0
Karte 1: NVidia [HDA NVidia], Gerät 8: HDMI 0 [HDMI 0]
Sub-Geräte: 1/1
Sub-Gerät #0: subdevice #0
Karte 1: NVidia [HDA NVidia], Gerät 9: HDMI 0 [HDMI 0]
Sub-Geräte: 1/1
Sub-Gerät #0: subdevice #0
Welches der vielen Audiodevices das Richtige ist habe ich durch probieren ermittelt. Hierzu eigenet sich das in den alsa-utils enthaltene speaker-test Programm.
HDMI Kabel an den Fernseher anschließen. Lautstärke des Fernsehers beachten, also nicht zu niedrig einstellen.
Anschließend für jedes der aufgelisteten Geräte das Kommando:
speaker-test -Dplughw:<Karte>,<Gerät>
ausführen. Wobei <Karte> durch die Nummer der Karte und <Gerät> durch die Nummer des Gerätes ersetzt werden müssen. Also das Kommando um das erste Gerät der Liste zu testen wäre dann:
speaker-test -Dplughw:0,0
Bei mir war es plughw:1,7. Hat man das Device identifiziert kann man es als Alsa Default Device vereinbaren, in dem man die Datei /etc/asound.conf wir folgt anlegt:
pcm.!default {
type plug
slave.pcm {
type hw
card 1
device 7
}
}
Ich würde das Alsa System jetzt neu starten.
Für alle MythTV Anwender: In der Audiokonfiguration wird das Device mit ALSA:plughw:1,7, natürlich entsprechend eurer Karte/Gerät, angegeben.
Einfacher WMA nach MP3 Encoder
Da einige der Internetradiosender ihre Sendungen nur als WMA-Stream
ausstrahlen, mein N770 Webtablet aber nur MP3 wiedergeben lann habe ich,
natürlich nur zu Bildungszwecken, das folgende kleine Skript
geschrieben.
Es ist ein kleiner Webserver in Python der auf Port 8080 lauscht. Bei einem eingehenden Request, wobei es sich um einen beliebigen GET Request handeln muss, verbindet sich der Webserver mit der im run Kommando angegebenen mms Adresse und lädt den WMA-Stream in einen Transcoder, der ihn dann in einen MP3 Stream umwandelt. Der aus dem Transcoder gewonnene Datenstrom wird mit dem notwendigen Contentheader versehen und als Antwort auf den GET Request zurücksendet.
Das Skript ist in Python 2.5 geschrieben und benötigt die libmimms bindings für Python.
Source radio.py:
Auf der Kommandozeile startet man das Programm mit:
Es ist ein kleiner Webserver in Python der auf Port 8080 lauscht. Bei einem eingehenden Request, wobei es sich um einen beliebigen GET Request handeln muss, verbindet sich der Webserver mit der im run Kommando angegebenen mms Adresse und lädt den WMA-Stream in einen Transcoder, der ihn dann in einen MP3 Stream umwandelt. Der aus dem Transcoder gewonnene Datenstrom wird mit dem notwendigen Contentheader versehen und als Antwort auf den GET Request zurücksendet.
Das Skript ist in Python 2.5 geschrieben und benötigt die libmimms bindings für Python.
Source radio.py:
from os import curdir, sep
from BaseHTTPServer import BaseHTTPRequestHandler, HTTPServer
from libmimms.core import run
__author__="barmeier"
__date__ ="$04.01.2010 16:48:20$"
class MmsTranscoder(BaseHTTPRequestHandler):
def do_GET(self):
try:
self.send_response(200)
self.send_header('Content-type', 'audio/mpeg')
self.end_headers()
run("mms://radiotstation/livestream.wma",self.wfile)
except IOError:
self.send_error(404,'File Not Found: %s' % self.path)
def main():
try:
server = HTTPServer(('', 8080), MmsTranscoder)
print 'Welcome to the machine...'
server.serve_forever()
except KeyboardInterrupt:
print '^C received, shutting down server'
server.socket.close()
if __name__ == '__main__':
main()
Damit die automatische MP3 Kodierung
funktioniert habe ich die download Methode in der Datei libmms/core.py
gepatched. Das kann man sicher viel eleganter machen, aber ich wollte
endlich Radio hören.
download Methode für libmms/core.py:def download(url, outStream):
"Using the given options, download the stream to a file."
stream = libmms.Stream(url, 1e6)
bitrate= 128000
dec= enc= mx= None
#sys.stdout.flush()
dm = muxer.Demuxer("wma")
type="mp3"
stopped = False
for data in stream:
#f.write(data)
frames = dm.parse(data)
if frames:
for fr in frames:
# Assume for now only audio streams
if dec == None:
# Open decoder
dec = acodec.Decoder(dm.streams[fr[0]])
print 'Decoder params:', dm.streams[fr[0]]
# Decode audio frame
r = dec.decode(fr[1])
try:
if r:
if bitrate == None:
bitrate = r.bitrate
# Open muxer and encoder
if enc == None:
params = {'id': acodec.getCodecID(type),
'bitrate': bitrate,
'sample_rate': r.sample_rate,
'channels': r.channels}
print 'Encoder params:', params
mx = muxer.Muxer(type)
stId = mx.addStream(muxer.CODEC_TYPE_AUDIO, params)
enc = acodec.Encoder(params)
ss = mx.start()
outStream.write(ss)
outStream.flush()
enc_frames = enc.encode(r.data)
if enc_frames:
for efr in enc_frames:
ss = mx.write(stId, efr)
if ss:
outStream.write(ss)
outStream.flush()
except:
print "Client lost. Waiting for next ..."
stopped=True
break
if stopped:
break
stream.close()
Auf der Kommandozeile startet man das Programm mit:
sbamamoto/home$ python raodio.py
Einfach im Browser http://<rechnername>:8080 aufrufen und dann sollte es funktionieren.
Abonnieren
Posts (Atom)