seeseekey.net - Invictus Deus Ex Machina

Bei der Soft­ware hat es die Open Source Bewe­gung schon weit gebracht, für so ziem­lich jeden Anwen­dungs­fall gibt es auch eine freie Appli­ka­tion. Anders sieht das bei der Hard­ware aus. Hier ist vie­les noch pro­prie­tär. Damit das nicht auf ewig so bleibt gibt es Pro­jekte wie Open­Cores wel­ches unter http://opencores.org/ zu fin­den ist.

Die Projektübersicht von OpenCores

Die Pro­jekt­über­sicht von OpenCores

Gegrün­det im Okto­ber 1999 von Dam­jan Lam­pret, gibt es auf den Web­sei­ten des Pro­jek­tes eine Reihe von offe­nen Rechen­wer­ken bis hin zu gan­zen Pro­zes­so­ren. Geschrie­ben ist das ganze meist in einer Hard­ware­be­schrei­bungs­spra­che wie VHDL, Veri­log oder Sys­tem­Ve­ri­log. Die Lizen­zen vari­ie­ren je nach Pro­jekt meist zwi­schen der LGPL oder einer BSD Lizenz.

Auf mactricks.de gibt es eine schöne Anlei­tung um aus einem Teil eines Git Repo­si­to­ries ein Sub­re­po­sitory zu erzeu­gen. Aller­dings gibt es mit der Vari­ante ein Pro­blem. Wenn man das ganze mehr als zwei oder drei­mal machen möchte, wird es mit der Zeit ner­vig all diese Befehle einzugeben.

Aus die­sem Grund habe ich für das Extra­hie­ren eines Sub­pro­jek­tes aus einem Git Repo­sitory ein Skript geschrieben:

#!/bin/sh
# extractSubproject <orignal repopath> <new repopath> <subfolder> <new remote (optional)>

# clone repository
git clone --no-hardlinks $1 $2

# extract subproject
cd $2
git filter-branch --subdirectory-filter $3 HEAD
git reset --hard
git remote rm origin
rm -r .git/refs/original/
git reflog expire --expire=now --all
git gc --aggressive
git prune

# Add optional remote and push
if [ "$4" != "" ]; then
git remote add origin $4
  git push origin master
fi

Her­un­ter­ge­la­den wer­den kann sich das Skript auch unter https://github.com/seeseekey/archive/blob/master/Bash/Git/extractSubproject.sh.

Unter .NET kann man Assem­blies mit einem „Strong Name“ ver­se­hen. Die­ser sorgt dafür das dass Assem­bly ein­deu­tig iden­ti­fi­ziert wer­den kann. Möchte man einen sol­chen erstel­len so benö­tigt man zuerst ein Schlüs­sel­paar wel­ches mit dem „Strong Name Uti­lity“ ange­legt wird:

sn –k keypair.snk

Das Tool befin­det sich dabei im Win­dows SDK Ord­ner (z.B. C:\Program Files (x86)\Microsoft SDKs\Windows\v7.0A) wobei sich die Ver­sion des SDKs durch­aus unter­schei­den kann. Die erzeugte Snk-Datei wird dabei dem Pro­jekt hin­zu­ge­fügt. Anschlie­ßend stellt man in den Pro­jekt­ein­stel­lun­gen unter „Signing“ die ent­spre­chende Datei ein. In die­sem Tab ist es auch mög­lich eine neue Schlüs­sel­da­tei zu gene­rie­ren, so das man für den Schritt der Erzeu­gung nicht auf das „Strong Name Uti­lity“ ange­wie­sen ist.

Die Projektoptionen im Visual Studio

Die Pro­jek­top­tio­nen im Visual Studio

Bei der Signie­rung ist es wich­tig dar­auf zu ach­ten, das alle Biblio­the­ken eben­falls mit einem Strong Name ver­se­hen sind, sonst ver­wei­gert das Stu­dio die Signie­rung der Anwen­dung. Möchte man aus dem signier­ten Assem­bly den öffent­li­chen Schlüs­sel extra­hie­ren, so kommt wie­der das „Strong Name Uti­lity“ zur Anwendung:

sn -e Assembly.exe public.pk

Das Schlüs­sel­paar wel­ches man erzeugt hat, kann man dabei für alle eige­nen Anwen­dun­gen benut­zen. Es ist nicht nötig, für jede Anwen­dung ein eige­nes Schlüs­sel­paar zu erzeu­gen, da sich der „Sim­ple­Name“ bei jedem Assem­bly unterscheidet.

Wei­tere Infor­ma­tio­nen gibt es unter:
http://msdn.microsoft.com/en-us/magazine/cc163583.aspx
http://msdn.microsoft.com/en-us/library/h4fa028b%28v=vs.80%29.aspx

In vie­len PCs sind Onboard­sound­kar­ten mit einem Real­tek Chip­satz ver­baut. Nor­ma­ler­weise besit­zen diese einen Line In, einen Mikro­fon­ein­gang und einen Anschluss für die Audio­aus­gabe. Möchte man nun einen der Ein­gänge anders bele­gen, so wird das unter Win­dows 7 meist problematisch.

Der Realtek HD Audio-Manager

Der Real­tek HD Audio-Manager

Das liegt aller­dings nicht daran, das es nicht gehen würde, aber meist fehlt der „Real­tek HD Audio-Manager“ wel­cher dafür sorgt das man die Anschlüsse kon­fi­gu­rie­ren kann. Wenn man die­sen her­un­ter­lädt (in den Trei­bern ent­hal­ten) und anschlie­ßend etwas an die Ein­gänge steckt, so wird man gefragt wie der Anschluss (Ein­gang, Aus­gang) kon­fi­gu­riert wer­den soll.

Wie man Git auf einem Ubun­tu­ser­ver auf­setzt hatte ich vor eini­ger Zeit in einem Arti­kel beschrie­ben. Nach­teil der vor­ge­stell­ten Methode ist, das sie sich nur für einen Nut­zer eig­net. Natür­lich kann man mit die­ser Methode auch meh­rere Nut­zer zu dem Repo­si­to­ries ver­bin­den, hat damit aber keine Mög­lich­keit mehr Zugriffs­be­rech­ti­gun­gen für die Repo­si­to­ries zu setzen.

Als Lösung für das Pro­blem wird Gito­lite für die Nut­zer und Rech­te­ver­wal­tung genutzt. Im ers­ten Schritt wer­den auf dem Ser­ver die not­wen­di­gen Pakete installiert:

sudo apt-get install git openssh-server perl

Als nächs­ter Schritt wird der Nut­zer ange­legt, in wel­chem Gito­lite läuft und in die­sen gewechselt:

sudo useradd -m git
sudo su git

Danach geht es auch schon an die Instal­la­tion von Gitolite:

cd ~
git clone git://github.com/sitaramc/gitolite
mkdir bin
cd gitolite
./install -ln

Anschlie­ßend muss der öffent­li­che SSH Schlüs­sel von dem Rech­ner mit wel­chem auf das Sys­tem zugrif­fen wer­den soll in den Home Ord­ner des „git“ Nut­zers kopiert wer­den. Anschlie­ßend kann das Setup abge­schlos­sen werden:

cd ~/bin
./gitolite setup -pk $HOME/seeseekey.pub

Damit ist das Setup abge­schlos­sen und es kann an die Kon­fi­gu­ra­tion gehen. Dazu wird vom Rech­ner des­sen Public Key beim Setup benutzt wurde das ent­spre­chende admi­nis­tra­tive Repo­sitory geklont:

git clone git@192.168.1.128:gitolite-admin

Die Datei­struk­tur des Repo­si­to­ries sieht dabei wie folgt aus:

conf
  gitolite.conf
keydir
  seeseekey.pub

In dem Ver­zeich­nis „key­dir“ sind die SSH Schlüs­sel ent­hal­ten. Um einen Nut­zer hin­zu­zu­fü­gen reicht es ein­fach einen neuen öffent­li­chen Schlüs­sel in das Ver­zeich­nis zu legen und das ganze ins Git Repo­sitory ein­zu­brin­gen. Die eigent­li­che Kon­fi­gu­ra­tion der Repo­si­to­ries erfolgt in der „gitolite.conf“ Datei. Diese sieht nach der Erzeu­gung so aus:

repo gitolite-admin
    RW+     =   seeseekey

repo testing
    RW+     =        @all

Das bedeu­tet das es zwei Repo­si­to­res gibt, eines trägt den Namen „gitolite-admin“ und dient der Ver­wal­tung. Das zweite Repo­sitory ist „tes­ting“ auf das alle Nut­zer zugrei­fen dür­fen. Benö­tigt man nun ein neues Repo­sitory, so fügt man einen neuen „repo“ Abschnitt mit dem Namen und den ent­spre­chen­den Rech­ten hinzu. Sobald das ganze com­mi­tet und gepusht wurde, legt Gito­lite das neue Repo­sitory an. Wenn man bei den Schlüs­seln meh­rere SSH Schlüs­sel pro Nut­zer wünscht, so legt man dafür am bes­ten eine Ver­zeich­nis­struk­tur an:

keydir
  seeseekey
    rechner1
      seeseekey.pub
    rechner2
      seeseekey.pub

Möchte man ein Repo­sitory löschen so ent­fernt man es aus der „gitolite.conf“ und löscht es anschlie­ßend auch vom Ser­ver. Damit hat man eine Lösung für Git Ser­ver mit meh­ren Nut­zern und und ent­spre­chen­der Verwaltung.

Wer einen Dru­cker ohne Netz­werk­an­schluss besitzt, kann ihn mit Hilfe eines Raspberry Pi zu einem Netz­werk­drü­cker umrüs­ten. Dazu wer­den im ers­ten Schritt die not­wen­di­gen Pakete installiert:

sudo apt-get install avahi-daemon cups cups-pdf

Nach der Instal­la­tion geht es an die Kon­fi­gu­ra­tion. Dazu wird die „cupsd.conf“ bearbeitet:

sudo nano /etc/cups/cupsd.conf

Den Sek­tio­nen „<Loca­tion />“, „<Loca­tion /admin>“ und „<Loca­tion /admin/conf>“ wird dabei die Zeile:

Allow @Local

hin­zu­ge­fügt. Dane­ben sollte noch die Zeile:

Listen <IP Adresse>:631

hin­zu­ge­fügt wer­den. Das sorgt dafür das auf dem pas­sen­den Inter­face gehorcht wird. Danach geben wir in der Kon­sole fol­gen­des ein:

sudo adduser pi lpadmin
sudo service cups restart

Damit wird der Nut­zer „pi“ der Gruppe der Nut­zer hin­zu­ge­fügt wel­che Ein­stel­lun­gen vor­neh­men dür­fen. Außer­dem wird der CUPS Ser­vice neu­ge­star­tet, so das die Ände­run­gen in der Kon­fi­gu­ra­ti­ons­da­tei wirk­sam wer­den. Nun kann sich über die URL:

https://<IP Adresse>:631

mit dem Web­in­ter­face von CUPS ver­bun­den werden.

Das CUPS Webinterface

Das CUPS Webinterface

Im Web­in­ter­face wird nun unter dem Tab „Ver­wal­tung“ der Punkt „Frei­ge­ben von Dru­ckern wel­che mit die­sem Sys­tem ver­bun­den sind“ akti­viert. Bestä­tigt wird das ganze mit den Zugangs­da­ten des Nut­zers „pi“. Abschlie­ßend klickt man auf den But­ton „Ver­füg­bare Dru­cker auf­lis­ten“ und fügt die ange­schlos­se­nen Dru­cker hinzu und gibt ihn frei. Dazu muss das pas­sende Modell aus­ge­sucht und bestä­tigt werden.

Anschlie­ßend kann man den Dru­cker in sei­nem Betriebs­sys­tem hin­zu­fü­gen und über den Raspberry Pi dru­cken. Sollte wie­der erwar­ten kein Druck statt­fin­den, so liegt das meist am falsch gewähl­ten Dru­cker­typ. Mit der beschrie­be­nen Kon­fi­gu­ra­tion lässt sich auch von iOS Gerä­ten mit­tels Air­Print druchen.

Wenn man auf einem Win­dows Sys­tem die Bit­lo­cker­ver­schlüss­lung akti­viert, so öff­net sich ein Fens­ter in wel­chem der aktu­elle Sta­tus ange­zeigt wird. Bit­lo­cker ver­schlüs­selt dabei auch nach einem Neu­start und ähn­li­chen Unter­bre­chun­gen wei­ter. Aller­dings sieht man dabei nicht mehr den Fort­schritt, da das Sys­tem das Fens­ter nur beim Akti­vie­ren der Ver­schlüss­lung anzeigt. Um diese Infor­ma­tion trotz­dem abzu­fra­gen gibt man auf der Konsole:

manage-bde -status

ein. Die Aus­gabe zeigt dann wie es um die Ver­schlüss­lung steht:

Volume "C:" [System]
[Betriebssystemvolume]

    Größe:                    4492,21 GB
    BitLocker-Version:        Windows 7
    Konvertierungsstatus:     Verschlüsselung wird durchgeführt
    Verschlüsselt (Prozent):  44 %
    Verschlüsselungsmethode:  AES 128 mit Diffuser
    Schutzstatus:             Der Schutz ist deaktiviert.
    Sperrungsstatus:          Entsperrt
    ID-Feld: Kein

Wich­tig ist dabei, das die ent­spre­chende Kon­sole als Admi­nis­tra­tor gestar­tet wurde, sonst schlägt das Kom­mando fehl.

Sel­ten gab es einen Embed­ded Com­pu­ter so güns­tig wie den Raspberry Pi, also was liegt da näher sich einen sol­chen für den Hei­m­ein­satz zu besor­gen. Wenn man sich anschaut bei wel­chen Prei­sen Air­play Boxen anfan­gen, wird man mer­ken das ein Raspberry Pi mit einem ent­spre­chen­den WLAN Stick und einem Boxen­sys­tem immer noch güns­ti­ger ist. Airplay-Boxen wel­che im Han­del erhält­lich sind begin­nen ab 200 € mit einer nach oben offe­nen Grenze.

Für einen Raspberry Pi, Air­play Ser­ver benö­tigt man:

  • einen Raps­berry Pi
  • ein Gehäuse für den Pi
  • einen WLAN Stick
  • ein paar Boxen

Im ers­ten Schritt sollte man sich eine Raspberry Pi Dis­tri­bu­tion her­un­ter­la­den, in die­sem Fall wird Ras­pian benutzt. Dazu wird das Image her­un­ter­ge­la­den und ent­packt. Anschlie­ßend hat man auf dem Rech­ner eine .img Datei. Diese muss nun auf die SD Karte geflasht wer­den. Um her­aus­zu­fin­den, wel­ches Volume nun geflasht wer­den muss, kann man sich auf dem Ter­mi­nal unter Mac OS X mit­tels „df -h“ anschauen wel­ches Gerät dazu­kommt. Eine andere Mög­lich­keit ist es die Karte über den Namen zu iden­ti­fi­zie­ren, wel­cher bei neuen Kar­ten meist „NO NAME“ oder „Untit­led“ sein sollte.

Wenn das pas­sende Gerät iden­ti­fi­ziert wurde, sollte die gemoun­tete Par­tion mittels:

diskutil unmount /dev/disk2s1

wie­der frei­ge­ge­ben wer­den. Nun wech­selt man im Ter­mi­nal in den Ord­ner in wel­chem die Image­da­tei liegt und gibt dabei fol­gen­des ein:

sudo dd bs=1m if=raspbian.img of=/dev/rdisk2

Zu beach­ten ist dabei das aus „disk2s1“ -> „rdisk2“ wird, womit das Gerät direkt ange­spro­chen wird. Theo­re­tisch würde auch „disk2“ funk­tio­nie­ren, aller­dings geht die Über­tra­gungs­ge­schwin­dik­eit hier­bei dras­tisch in den Kel­ler. Nach dem flas­hen der Karte wird das Gerät mittels:

diskutil eject /dev/rdisk2

aus­ge­wor­fen. Die Karte kann nun in den aus­ge­schal­te­ten Pi gelegt wer­den und die­ser mit Strom ver­sorgt wer­den. Beim ers­ten Start wird man vom Kon­fi­gu­ra­ti­ons­menü „raspi-config“ begrüßt. Hier kann man das Tas­ta­tur­lay­out, den SSH Ser­ver und andere Dinge ein­stel­len. Wir stel­len ein deut­sches Tas­ta­tur­lay­out ein und akti­vie­ren den SSH Ser­ver. Des­wei­te­ren sollte man das Pass­wort für den Nut­zer Pi ändern und die root Par­tion auf den gesam­ten Bereich der SD Karte aus­deh­nen. Anschlie­ßend kann man den Pi neustarten.

Für das draht­lose Netz wird der WLAN Stick an den Raspberry Pi ange­schlos­sen. Wenn man dies im lau­fen­den Betrieb macht kann es pas­sie­ren das der Pi anschlie­ßend neu­star­tet. Das ganze sieht etwas nach einer Brow­nout Detec­tion aus, sprich der Raspberry hat für einen Moment zu wenig Strom und star­tet neu.

In der Kon­sole kann man nun mit­tels „ifcon­fig“ fest­stel­len ob ein wei­te­res Netz­werk­ge­rät hin­zu­ge­kom­men ist. Dort soll­ten die Geräte „eth0“, „lo“ und „wlan0“ auf­tau­chen. Nun geht es an die Kon­fi­gu­ra­tion des WLANs. Dazu wird die „/etc/network/interfaces“ mit­tels „nano“ aufgerufen:

sudo nano /etc/network/interfaces

Dabei wer­den einige Ände­run­gen in der Datei vor­ge­nom­men. Anschlie­ßend sollte die „inter­faces“ Datei wie folgt aussehen:

auto lo

iface lo inet loopback
iface eth0 inet dhcp

allow-hotplug wlan0
auto wlan0
iface wlan0 inet dhcp
pre-up wpa_supplicant -B w -D wext -i wlan0 -c /etc/wpa_supplicant/wpa_supplicant.conf
iface default inet dhcp

Nun geht es an die Kon­fi­gu­ra­tion der „/etc/wpa_supplicant/wpa_supplicant.conf“ Datei. Diese sollte nach der Kon­fi­gu­ra­tion in etwa so aussehen:

ctrl_interface=DIR=/var/run/wpa_supplicant GROUP=netdev
update_config=1

network={
  ssid="WLAN"
  scan_ssid=1
  proto=RSN
  key_mgmt=WPA-PSK
  pairwise=CCMP
  group=CCMP
  psk="geheim"
}

Im vor­lie­gen­den Bei­spiel wurde ein WPA 2 ver­schlüs­sel­tes WLAN ein­ge­rich­tet. Bei einem Neu­start sollte das WLAN anschlie­ßend ver­füg­bar sein. Ist dies nicht der Fall, so kann der Pro­zess mittels:

sudo wpa_supplicant -i wlan0 -D wext -c /etc/wpa_supplicant/wpa_supplicant.conf -d

manu­ell akti­viert wer­den. Dabei sieht man dann auch ent­spre­chende Feh­ler­mel­dun­gen, wel­che auf Pro­bleme hin­wei­sen kön­nen. Wenn die WLAN Schnitt­stelle aktiv ist, kann man auf einem ande­ren Ter­mi­nal mit­tels „iwcon­fig“ sehen ob die Schnitt­stelle funk­tio­niert. Dies ist dann gege­ben wenn die Schnitt­stelle nicht mehr als „unas­so­cia­ted“ mar­kiert ist.

Der letzte Punkt der jetzt noch fehlt ist die Unter­stüt­zung für Air­play. Hier­für wird Shair­port instal­liert. Dazu wer­den im ers­ten Schritt die not­wen­di­gen Biblio­the­ken instal­liert, sowie der Quell­code von Shair­port und dem SDP Modul auf den Pi geholt:

sudo apt-get install git libao-dev libssl-dev libcrypt-openssl-rsa-perl libio-socket-inet6-perl libwww-perl avahi-utils libmodule-build-perl
git clone git clone https://github.com/njh/perl-net-sdp.git
git clone git://github.com/abrasive/shairport.git

Bevor Shair­port kom­pi­liert wird, muss das SDP Modul instal­liert wer­den. Dazu wech­seln wie in den Ord­ner und geben dort fol­gen­des ein:

perl Build.PL
sudo ./Build
sudo ./Build test
sudo ./Build install

Danach wech­seln wir in den Shair­port Ord­ner und geben dort „make“ ein. Anschlie­ßend kön­nen wir ganze mit­tels „perl shairport.pl“ star­ten und einen ers­ten Test vor­neh­men. Nun müs­sen wir noch dafür sor­gen das Shair­port beim Start des Pi auch gestar­tet wird. Außer­dem soll der Emp­fän­ger noch einen ordent­li­chen Namen bekom­men. Dazu geben wir im Shair­port Ord­ner fol­gen­des ein:

sudo make install
sudo cp shairport.init.sample /etc/init.d/shairport
cd /etc/init.d
sudo chmod a+x shairport
sudo update-rc.d shairport defaults
sudo nano shairport

Nach­dem wir die Datei „shair­port“ in „nano“ geöff­net haben, ändert wir dort den Namen z.B. in Schlaf­zim­mer oder Wohn­zim­mer. Damit bekommt der Emp­fän­ger einen ein­deu­ti­gen Namen. Nach einem Neu­start oder einem manuellen:

./shairport start

ist der eigene Air­Play Emp­fän­ger fertig.

Wei­tere Infor­ma­tio­nen gibt es unter:
http://wiki.ubuntuusers.de/WLAN
http://wiki.ubuntuusers.de/WLAN/wpa_supplicant
http://netz10.de/2010/02/13/wlan-wpa2-mit-psk-manuell-konfigurieren/

Wer unter Mac OS X einen Hexe­di­tor benö­tigt der sollte sich ein­mal 0xED anschauen. Der Edi­tor bie­tet dabei eine Menge nütz­li­che Funk­tio­nen wie die auto­ma­ti­sche Umrech­nung der selek­tier­ten Daten in bekannte Daten­ty­pen und Stan­dard­fea­tures wie das Suchen in den Daten, sowie die Unter­stüt­zung von Little- und Bigendian.

0xED mit geöffneter Datei

0xED mit geöff­ne­ter Datei

0xED ist dabei in unter ande­rem ins Deut­sche loka­li­siert wor­den. Bezo­gen wer­den kann der Edi­tor unter http://www.suavetech.com/0xed/.

Wäh­rend das Linux auf einem Raspberry Pi ohne Pro­bleme geup­datet wer­den kann, sieht dies bei der Firm­ware etwas anders aus. Hier ist Hand­ar­beit gefragt. Dazu wird im ers­ten Schritt Git installiert:

sudo apt-get install git

Damit das Update der Firm­ware nicht in Arbeit aus­ar­tet, sollte man „rpi-update“ nut­zen, wel­ches unter https://github.com/Hexxeh/rpi-update/ zu fin­den ist. Mittels:

sudo wget http://goo.gl/1BOfJ -O /usr/bin/rpi-update && sudo chmod +x /usr/bin/rpi-update

wird das ganze auf dem Raspberry Pi instal­liert. Nun kann das Firm­ware Update mit:

sudo rpi-update

ange­sto­ßen wer­den. Die Dauer eines Updates beträgt etwa fünf Minu­ten. Nach dem erfolg­rei­chen Update muss der Raspberry Pi neu­getstar­tet werden.