carrier-lost.org

Die Verwendung der ssh config Datei erlaubt es zusätzlich unterschiedliche private ssh keys zu verwenden.

Dazu dem jeweiligen Eintrag noch die Option

IdentityFile ~/.ssh/id_rsa.work

mit dem Pfad zur Datei hinzufügen.

Quick howto on how to install truecrypt on the rapberry pi.

Get the source for Mac OS X/Linux from http://www.truecrypt.org/downloads2 and copy the file to the pi:

pat@earth Downloads]$ scp TrueCrypt\ 7.1a\ Source.tar.gz pi@pi:/home/pi/

Connect to the pi and extract the archive:

pi@raspberrypi ~ $ tar xfv TrueCrypt\ 7.1a\ Source.tar.gz

Even without a GUI, you’ll need WxWidget. Download and extract:

pi@raspberrypi ~ $ wget http://prdownloads.sourceforge.net/wxwindows/wxWidgets-2.8.12.tar.gz
pi@raspberrypi ~ $ tar xfv wxWidgets-2.8.12.tar.gz

Install the fuse library:

pi@raspberrypi ~ $ sudo aptitude install libfuse-dev

Create a folder and download some needed header files:

pi@raspberrypi ~ $ mkdir ~/truecrypt-7.1a-source/pkcs
pi@raspberrypi ~ $ wget ftp://ftp.rsasecurity.com/pub/pkcs/pkcs-11/v2-20/*.h -P truecrypt-7.1a-source/pkcs/

Change to the truecrypt directory and compile WxWidgets (takes about 20 minutes):

pi@raspberrypi ~ $ cd truecrypt-7.1a-source/
pi@raspberrypi ~/truecrypt-7.1a-source $ export PKCS11_INC=/home/pi/truecrypt-7.1a-source/pkcs/
pi@raspberrypi ~/truecrypt-7.1a-source $ make NOGUI=1 WX_ROOT=/home/pi/wxWidgets-2.8.12 wxbuild

Now compile truecrypt (~ 40 minutes):

pi@raspberrypi ~/truecrypt-7.1a-source $ make NOGUI=1 WXSTATIC=1

Copy the binary into the bin directory:

pi@raspberrypi ~/truecrypt-7.1a-source $ sudo cp Main/truecrypt /usr/local/bin/

Mount your container:

pi@raspberrypi ~/truecrypt-7.1a-source $ truecrypt -t -k “” –protect-hidden=no –mount /mnt/usb/crypt /mnt/truecrypt/ -m=nokernelcrypto

Cleanup:

pi@raspberrypi ~/truecrypt-7.1a-source $ cd ~
pi@raspberrypi ~ $ rm -r truecrypt-7.1a-source TrueCrypt\ 7.1a\ Source.tar.gz wxWidgets-2.8.12*

Edit: I uploaded the binary. If you don’t want to compile truecrypt yourself, feel free to use this one.

Vor ein paar Tagen habe ich Mainboard und CPU beim media pc getauscht. Das neue Board ist ein DH67BL von Intel und hat einen anderen Soundprozessor verbaut. Leider wird dieser vom aktuellen Paket im Repo nicht unterstützt.

Erkannt wird er als:

cat /proc/asound/card0/codec#0  | grep Codec
Codec: Realtek ALC892

 

Hier bzw. hier wird eine Lösung beschrieben.

Kurzfassung:

wget http://files.spacefish.biz/LinuxPkg-5.15rc1.tar.bz2
tar xvfj LinuxPkg-5.15rc1.tar.bz2
cd realtek-linux-audiopack-5.15

Bei Nicht-Ubuntu Systemen soll es wohl reichen, das install skript auszuführen, laut Readme.txt ist die Vorgehensweise etwas anders:

tar xvjf alsa-driver-1.0.23-5.15rc1.tar.bz2
cd alsa-driver-1.0.23
./configure –with-cards=hda-intel
make
sudo make install

Theoretisch kann man auch das install skript ausführen und den Fehler am Ende ignorieren, da es genau das selbe macht. Nach einem Neustart noch im alsamixer alle Kanäle “unmuten”.

Zur Installation von Ubuntu gibt es im Netz genügend Quellen und Anleitungen, die jeder an seine eigenen Bedürfnisse (RAID, LVM, Verschlüsselung) anpassen kann. Aus diesem Grund setze ich eine frische Installation voraus. Bei der Installation wurde der Nutzer xbmc angelegt.

1. Netzwerk

Da in diesem Setup auf die Installation einer grafischen Oberfläche wie Gnome oder KDE verzichtet wird, muss die Konfiguration über die Shell und nicht z.B. den Network Manager erfolgen. Im Wiki findet man eine passende Anleitung für die Einrichtung einer WLAN Verbindung mittels wpa_supplicant. Je nach WLAN Chip, kann es nötig sein, Kernelmodule zu laden bzw. zu blacklisten.

Als Beispiel hier die Konfiguration (/etc/network/interfaces) für ein WLAN mit WPA2 Verschlüsselung und fester IP:

auto lo
iface lo inet loopback auto wlan0

iface wlan0 inet static
address 192.168.1.2
gateway 192.168.1.1
dns-nameservers 8.8.8.8
netmask 255.255.255.0
wpa-driver wext
wpa-ssid WLAN
wpa-ap-scan 1
wpa-proto RSN
wpa-pairwise CCMP TKIP
wpa-group CCMP TKIP
wpa-key-mgmt WPA-PSK
wpa-psk _HIER_WPA2_KEY_EINTRAGEN_

 

2. Autologin

Als nächstes wird das automatische Anmelden eingerichtet. Dazu wird rungetty installiert

aptitude install rungetty

und anschließend in der Datei /etc/init/tty1.conf, die Zeile

exec /sbin/getty 38400 tty1

durch die folgende ersetzt

exec /sbin/rungetty –autologin BENUTZERNAME tty1

Dabei natürlich BENUTZERNAME durch euren Benutzer ersetzen. In diesem Kontext also mit xbmc.

 

3. Xorg & nvidia

Installation des Xservers und der proprietären Nvidia Grafiktreiber

aptitude install xorg aptitude install nvidia-current

Evtl. reicht anschließend der Aufruf von

nvidia-xconfig

um eine geeignete Grundkonfiguration für den Xserver zu erstellen.

Hier meine /etc/X11/xorg.conf für eine Geforce GT220 und einen LG 37LH4000 LCD-TV.

Section “ServerLayout”
Identifier     “Prop. Nvidia”
Screen      0  “Screen” 0 0
EndSection

Section “ServerFlags”
Option      “Xinerama” “off”
EndSection

Section “Module”
Load    “glx”
EndSection

Section “Monitor”
Identifier  “LG LCD”
Option      “VendorName” “LG”
Option      “ModelName” “37LH4000″
Option      “DPMS” “true”
Option      “PreferredMode” “1920×1080″
Option      “Position” “0 0″
Option      “Rotate” “normal”
Option      “Disable” “false”
Option      “TargetRefresh” “50″
Option      “DPI” “180 x 180″
EndSection

Section “Device”
Identifier  “Geforce GT220″
Driver  “nvidia”
Option  “NoLogo”                “true”
Option  “DynamicTwinView”       “false”
Option  “FlatPanelProperties”   “Scaling = Native”
Option  “ModeValidation”        “NoVesaModes, NoXServerModes”
Option  “ModeDebug”             “true”
Option  “HWCursor”              “false”
EndSection

Section “Screen”
Identifier “Screen”
Device     “Geforce GT220″
Monitor    “LG LCD”
DefaultDepth     24
SubSection “Display”
Depth     24
Modes  “1920x1080_50″ “1920x1080_60_0″ “1920x1080_30″ “1920x1080_25″ “1920x1080_24″  “1920x1080_50i” “1920x1080_60i”
EndSubSection
EndSection

Section “DRI”
Mode         0666
EndSection

 

4. Sound

Wir verwenden zur Tonausgabe ALSA, diese erfolgt über die onboard Soundkarte, genauer: über den optischen Digitalausgang an einen externen Verstärker. Wer den Ton über hdmi ausgeben möchte, findet hier oder hier evtl. Hilfe.

aptitude install alsa-base alsa-utils
alsamixer

Im Alsamixer alle Spuren am besten ein wenig aufdrehen. Darauf achten, dass unter den Spuren kein MM steht. Das bedeutet, dass die Spur gemutet ist. Zum “laut schalten” die Spur auswählen und m drücken. Außerdem muss der Benutzer noch zur audio Gruppe hinzugefügt werden. Dies passiert mit

usermod -a -G audio xbmc

 

5. XBMC

Das xbmc Repository hinzufügen

aptitude install python-software-properties
add-apt-repository ppa:team-xbmc/ppa
aptitude update

und anschließend die standalone version von xbmc mit allen Abhängigkeiten installieren

aptitude install xbmc-standalone

Den korrekten Start kann man nun mit

xinit xbmc-standalone

testen. Damit das xbmc zukünftig automatisch gestartet wird, fügen wir die Zeilen

if [ -z "$DISPLAY" ] && [ $(tty) == /dev/tty1 ]; then
xinit /usr/bin/ck-launch-session /usr/bin/xbmc-standalone
fi

in die Datei .bash_profile ein.

 

6. Fernbedienung mit Lirc

Verwendet wird die HP Media Center Fernbedienung (diese hier), welche von lsusb als

Bus 004 Device 002: ID 0471:0815 Philips eHome Infrared Receiver

erkannt wird. Nach der Installation von lirc mittels

aptitude install lirc

sollte automatisch der Konfigurationsdialog starten. Für die oben genannte Fernbedienung

Windows Media Center Transceivers/Remotes (all)

und

Microsoft Windows Media Center V2 (usb) : Direct TV Receiver

auswählen. Abschließend den lirc daemon noch zum Autostart hinzufügen:

update-rc.d lirc enable default

Im xbmc sollte keine weitere Konfiguration nötig sein.

 

7. Power Management

Das udisks Paket mit allen Abhängigkeiten mittels

aptitude install udisks

installieren und die Datei /var/lib/polkit-1/localauthority/50-local.d/custom-actions.pkla mit dem Inhalt

[Actions for xbmc user]
Identity=unix-user:xbmc
Action=org.freedesktop.upower.*;org.freedesktop.consolekit.system.*;org.freedesktop.udisks.*
ResultActive=yes

erstellen.

Jetzt nur noch das xbmc selbst einrichten und das war es. Viel Vergnügen!

Quellen:
http://wiki.ubuntuusers.de/autologin
http://wiki.xbmc.org/?title=XBMCbuntu
http://wiki.xbmc.org/index.php?title=HOW-TO_install_XBMC_for_Linux_on_Ubuntu_with_a_minimal_installation,_an_unofficial_Step-by-Step_Guide
http://forum.xbmc.org/showthread.php?t=38804
http://wiki.ubuntuusers.de/lirc
http://wiki.xbmc.org/index.php?title=Ubuntu_Suspend_/_Wake
http://forum.xbmc.org/showthread.php?t=73236
http://www.loggn.de/ubuntu-xbmc-10-0-dharma-pvr-repository/

Hat man sich einmal an die Vorteile von public key Authentifizierung bei einem System gewöhnt, stellt man meist zügig alle anderen Systeme ebenfalls auf diese Art der Authentifizierung um. Möchte man sich von verschiedenen Systemen aus anmelden, muss der eigene private Key auf diese kopiert oder z.B. per USB-Stick mit sich geführt werden. Kommt dieser allerdings in falsche Hände, muss man einen neuen Schlüssel generieren und erneut an alle Systeme verteilen. Zum Schutz des privaten Keys, ist es möglich, diesen mit einem Passwort (besser: Passphrase) zu schützen. Dieses wird benötigt um den Key “freizuschalten”, die eigentliche Anmeldung am entfernten System läuft weiterhin über das public key Verfahren und benötigt kein Passwort.  Für eine einfachere Unterscheidung wird das Kennwort zur Freischaltung deshalb auch als “Passphrase” und nich als Passwort bezeichnet. Sollte man den privaten Schlüssel bei der Erstellung nicht mit einer Passphrase versehen haben, kann man dies noch nachträglich mit ssh-keygen tun.

[pat@earth ~]$ ssh-keygen -p
Enter file in which the key is (/home/pat/.ssh/id_rsa):  [Enter]
Key has comment ‘/home/pat/.ssh/id_rsa’
Enter new passphrase (empty for no passphrase):  newSuperSavePassword
Enter same passphrase again:  newSuperSavePassword
Your identification has been saved with the new passphrase.

Quellen:

http://kimmo.suominen.com/docs/ssh/#passwd

http://www.manpagez.com/man/1/ssh-keygen/

Für den Netzzugang über ein virtuelles privates Netz (VPN) gibt es sicherlich eine ganze Menge guter Gründe, einer davon ist z.B. die Überwindung der geobasierten Sperrung von Webseiten à la Youtube (“Dieses Video ist in deinem Land nicht verfügbar”). Auf Amerika beschränkte Angebote wie der Streaming Dienst Hulu sind damit in Deutschland nutzbar. Der Anbieter VPN on Demand befindet sich seit einiger Zeit in der Betaphase und ermöglicht einen kostenlosen VPN Zugang. Dazu einfach eine E-Mail mit dem Betreff “vpnod” an promotion@vpnod.com schicken und kurze Zeit später gibt es die Zugangsdaten per E-Mail.

Als erstes muss der PPTP-Client installiert werden. Unter Arch Linux mittels

[pat@earth ~]$ sudo pacman -S pptpclient

unter Debian und Ubuntu heißt das Paket pptp-linux und wird mittels

[pat@earth ~]$ sudo aptitude install pptp-linux

installiert. Nach der Installation konfigurieren wir eine neue VPN Verbindung, hier im Beispiel von VPN on Demand. Dazu legen wir im Verzeichnis /etc/ppp/peers eine Datei für die neue VPN-Verbindung an und tragen folgendes ein: (Die im folgenden verwendeten Variablen $BENUTZER und $PASSWORT sind natürlich mit den erhaltenen Zugangsdaten zu ersetzen)

[pat@earth ~]$ sudo vim /etc/ppp/peers/vpnod

pty “pptp vpn.vpnod.com –nolaunchpppd”
name $USER
linkname vpnod
remotename vpnod
ipparam vpnod
usepeerdns
require-mppe-128
file /etc/ppp/options.pptp

In der Datei chap-secrets werden nun die Zugangsdaten definiert.

[pat@earth ~]$ sudo vim /etc/ppp/chap-secrets

$BENUTZER vpnod $PASSWORT *

Zum testen starten wir das VPN und setzen die Schnittstelle als Standardgateway, so dass der gesamte Internetverkehr über das VPN läuft. Am besten vorher und nachher diese Seite zur Überprüfung der eigenen IP besuchen. Hinweis: Ab diesem Zeitpunkt wird jeglicher Traffic über das VPN geroutet, d.h. auch E-Mails, Instant Messenger oder andere Anwendungen die auf dem System laufen. Die Daten sind zwar bis zur VPN Gegenstelle verschlüsselt, ab dort ist es allerdings Aufgabe des Anwenders für die Verschlüsselung zu sorgen. Wer dem VPN Anbieter nicht traut (oder leicht zu Paranoia neigt ) sollte hier die selben Sicherheitsvorkehrungen wie bei der Nutzung eines öffentlichen WLAN Hotspots, sprich HTTPS/SSL, vornehmen.

[pat@earth ~]$ sudo pon vpnod
[pat@earth ~]$ sudo route add default dev ppp0

Sollte der Verbindungsaufbau scheitern, kann der Aufruf von pon mittels

[pat@earth ~]$ sudo pon vpnod debug dump logfd 2 nodetach

bei der Fehlersuche hilfreich sein.

Zum Abbau der Verbindung, die Route wieder entfernen (sollte poff automatisch machen) und die Verbindung trennen.

[pat@earth ~]$ sudo route del default
[pat@earth ~]$ sudo poff

Klappt alles ohne Probleme, kann man das ganze nun automatisieren. Alle Scripte (*.sh) im Ordner /etc/ppp/if-up.d/ werden automatisch nach dem Aufbau der VPN Verbindung ausgeführt. Da Rounting eine komplexe Sache und ein Post für sich wäre, hier nur beispielhalt ein Script zum routen des gesammten Traffics über das VPN.

pat@earth ~]$ sudo vim /etc/ppp/ip-up.d/10-route.sh

#!/bin/bash

# Interface (eth0 or wlan0 in most cases)
INTERFACE=eth0

# Interface as provided by calling pppd
VPN=$1
#VPN=ppp0

route del default ${INTERFACE}
route add default dev ${VPN}

Und erstellen ein weiteres Script, welches nach dem Abbau der VPN Verbindung wieder die richtige Route einträgt.

[pat@earth ~]$ sudo vim /etc/ppp/ip-down.d/10-route.sh
#!/bin/bash

# Interface (eth0 or wlan0 in most cases)
INTERFACE=eth0

# Interface as provided by calling pppd
VPN=$1

# Gateway (use ‘route’ to find out, IP or name)
GATEWAY=192.168.2.1

route del default ${VPN}
route add default gw ${GATEWAY} ${INTERFACE}

Ist der Hostname oder die IP des Gateways nicht bekannt, hilft das Kommando route.

[pat@earth ip-up.d]$ route
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
192.168.2.0 * 255.255.255.0 U 202 0 0 eth0
default 192.168.2.1 0.0.0.0 UG 202 0 0 eth0

Eine Möglichkeit das Ganze nun automatisch beim Systemstart zu machen, findet man für Arch Linux z.B. hier.

Quellen: http://pptpclient.sourceforge.net

Auch wenn ich der Meinung bin, man sollte lieber das Jabber Protokoll für Instant Messenger nutzen, wie beispielsweise Google es bei Google Talk macht, ist ICQ wohl immer noch in Deutschland am weitesten verbreitet. Gründe für den Wechsel findet man z.B. bei Wikipedia.

Gelegentlich kommt es vor, dass Änderungen am ICQ Protokoll oder an der Infrastruktur vorgenommen werden und sich alternative Clients kurzzeitig nicht anmelden können. Genau das ist wohl dieses Wochenende passiert. Da laut offizieller Pidgin homepage nur Sicherheitsupdates außerhalb des Releasezyklus von Ubuntu angeboten werden, gibt es wohl erstmal keine automatisierte Lösung des Problems. In diversen Foren gibt es mittlerweile verschiedene Lösungen, wobei das Deaktivieren von SSL die einfachste, allerdings auch “unschönste” Lösung ist, da somit eure Logindaten unverschlüsselt übertragen werden. Am sinnvollsten erscheint mir da die Installation des pidgin ppa und Aktualisierung auf das neuste Release.

Vorgehensweise:

• Installer paket herunterladen: Pidgin PPA Package
• Rechtsklick auf die Datei und “Mit GDebi Paket-Installationsprogramm öffnen” auswählen
• Rechts auf den Button “Paket installieren” klicken
• Nach der Installation die Aktualisierungsverwaltung öffnen (Unter xfce: Startmenü -> System)
• Auf Aktualisierungen überprüfen und anschließend installieren
• Pidgin neustarten und die Einstellungen für das ICQ Konto öffnen (Konten -> ICQ -> Konto bearbeiten)
• Auf dem Reiter Erweitert den Server auf slogin.icq.com ändern und ein Häkchen bei “Benutze SSL” und “clientLogin benutzen” setzen

Danach sollte die Anmeldung am ICQ Server auch über SSL wieder funktionieren. Außerdem bekommt ihr durch die PPA Installation jetzt immer die neuste Version von Pidgin bequem über die Aktualisierungsverwaltung.

OpenWRT is a linux distribution for embedded devices like a router. The installation of OpenWRT on your device instead of the original vendor’s firmware allows you to do some nifty stuff with your router like installing additional software out of openWRT’s own repository.

Although there is a package for the openSSH server available, dropbear is the default choice. To enable password-less ssh access you first need to generate the ssh keys on your client machine if you haven’t already. If you want, you can secure your key by typing in a password, otherwise just press enter.

pat@earth:~$ ssh-keygen

Next you have to transfer your public key (the file ending with .pub) to your openWRT installation.

pat@earth:~$ scp ~/.ssh/id_rsa.pub 192.168.1.1:/tmp/

Replace 192.168.1.1 with the IP of your router. If you changed the Port of your ssh server, you have to define it using the -P parameter like scp -P 4321 etc.

Connect to your router and add the transferred public key file to your authorized_keys. Unlike OpenSSH, Dropbear doesn’t look in .ssh underneath your home directory for the authorized_keys file, so you have to create the file in /etc/dropbear/.

root@router:~# cd /etc/dropbear/
root@router:~# cat /tmp/id_rsa.pub >> authorized_keys
root@router:~# chmod 0600 authorized_keys

Now you should be able to ssh from your client pc to your openWRT device without the need of a password.

The rt2800usb module is quite buggy, so you have to blacklist it and use rt2870sta instead.

Information

pat@htpc:~$ lsusb
Bus 001 Device 002: ID 148f:2870 Ralink Technology, Corp.

Syslog

htpc kernel: [ 5.273678] Registered led device: rt2800usb-phy0::radio
htpc kernel: [ 5.273689] Registered led device: rt2800usb-phy0::assoc
htpc kernel: [ 5.273710] Registered led device: rt2800usb-phy0::quality
htpc kernel: [ 5.274304] usbcore: registered new interface driver rt2800usb

Blacklist

echo blacklist rt2800usb | sudo tee -a /etc/modprobe.d/blacklist.conf
echo blacklist rt2x00usb | sudo tee -a /etc/modprobe.d/blacklist.conf

Restart and you’re fine.

Versucht man Ubuntu Alternate oder Server von einem USB Stick zu installieren, meckert der Installer, dass er das CDRom Laufwerk nicht finden kann bzw. die Installations-CD nicht eingehangen ist. Abhilfe schafft das Anhängen des Kernelparameters

cdrom-detect/try-usb=true

hinter /install/vmlinuz oder /ubnkern, falls der USB Stick mit UNetBootin erstellt wurde. In der syslinux.cfg sieht das dann beispielsweise so aus:

label unetbootindefault
menu label Default
kernel /ubnkern
append initrd=/ubninit vga=normal cdrom-detect/try-usb=true — quiet

label ubnentry1
menu label ^Install
kernel /install/netboot/ubuntu-installer/amd64/linux
append initrd=/install/netboot/ubuntu-installer/amd64/initrd.gz vga=normal cdrom-detect/try-usb=true — quiet

Quelle: http://forum.ubuntuusers.de/topic/alternate-installation-via-usb-stick-unter-wi/