Floppy’s an einem Android

Neulich kam der Joshi mit der Idee es zu versuchen, ob es möglich ist, ein Android-Tablett-Computer mit einem externen Diskettenlaufwerk zu verbinden, um auf die Daten einer 3,5″-Diskette zu zugreifen. Schliesslich besitzen die meisten Android-Geräte einen Mini- oder Micro-USB-Anschluss.
Also habe ich mal mein externes Diskettenlaufwerk mitgebracht. Joshi hat auch noch ein USB-OnTheGo-Kabel mitgebracht, welches nötig ist, damit die mobilen Touch-Geräte als Host-Controller die Peripherie-Geräte anbinden können. Dieses OnTheGo-Kabel dient damit praktisch als Adapter von Mini-USB auf eine normale USB-Buchse Typ A. Das Tablet war ein Nexus-Gerät mit dem CyanogenMod als Betriebssystem.
Nach dem erstmaligen Zusammenschluss der Hardware und einlegen einer Diskette in das Laufwerk, hat das Nexus das Laufwerk direkt als USB-Massenspeicher erkannt. Solch ein Diskettenlaufwerk mit einem Medium, welches maximal eine Speicherkapazität von 1,44 Megabyte besitzt, als Massenspeicher zu bezeichnen, muss mal hier aber wohl als Euphemismus bezeichnen. Die kleinsten USB-Sticks, die man derzeit für Geld im Laden kaufen kann, sind welche mit 2 Gigabyte.

Unbenannt

Wie sich später aber heraus stellte, war die eine Diskette des ersten Versuch bereits defekt, denn das Android versuchte allzeit den Datenträger mit einem FAT32-Dateisystem neu zu formatieren.
Mit einer anderen Diskette hatte es dann schliesslich geklappt. Das Betriebssystem erkannte das Medium und über den eigenen Dateimanager konnte man auf die Dateien zugreifen. Beweis dafür, dass Android sogar noch das alte FAT12-Dateisystem beherrscht. Anders als vermutet muss ausserdem im Kernel des Android wahrscheinlich kein Treibermodul für Floppy enthalten sein, da das Gerät logischerweise ja über USB-Massenspeicher angesprochen wird. Allerdings konnte man noch nicht auf eine Diskette schreiben, da offensichtlich für die Möglichkeit allgemein auf USB-Massenspeicher ausserhalb eines Android-Gerät die Schreibzugriffe fehlen. Hier muss wahrscheinlich das Gerät gerootet werden.
Es ergab sich aber noch ein anderer Nebeneffekt. Da auf einer weiteren Diskette, welche tatsächlich noch funktionierte, MIDI-Dateien gespeichert waren, stand natürlich der Versuch im Raum, diese zu öffnen. Auch dies klappte. Erkenntnis: Der Standartmedienplayer Apollo des CyanogenMod kann auch noch MIDI-Dateien abspielen.

Unbenannt

Die Essenz aus diesem kleinen Versuch ist, dass man auf die alten Daten von den kleinen 3,5″-Floppy’s auch mit den modernen smarten Geräten zugreifen kann.

Die Wolke in der eigenen Hand

Seit der iTunes-Version 11.2 und iOS 7.0.3 hat nun Apple das vollzogen, wovon ich nie gedacht hätte, dass es passieren würde. Man kann die Kalender- und Kontaktdaten nun nicht mehr lokal über WiFi oder USB zwischen Computer und iPhone/iPad synchronisieren. Stattdessen braucht man dazu seine Apple-ID um das über die iCloud abzugleichen. Aber die iCloud kommt für mich nicht in Frage, da die Daten nichts auf fremden Servern zu suchen haben, die zu allen Überfluss auch noch im Ausland stehen. Ich weis schliesslich nicht, ob sie dort auch verschlüsselt abgelegt werden und muss eventuell davon ausgehen, dass irgendwelche staatlichen Behörden auf diese Server zugriff haben. Deswegen habe ich nun beschlossen, einen meiner Raspberry Pi’s dazu zu nutzen und auf ihn ownClod installieren, der sicher in meiner eigenen Wohnung steht. Mit ihm werde ich meine Kalender- und Kontaktdaten über mein lokales Netz austauschen, währenddessen die Bilder-, Audio- und Applikationen sowieso ich über USB synchronisiere.

Raspberry Pi für ownCloud

Raspberry Pi für ownCloud

Anbei ein kleiner Workaround zur Installation von ownCloud.

Ich entscheide mich hierbei für den Webserver nginx, der wohl etwas Ressourcen schonender als der Apache-Webserver ist und flüssiger läuft.

Auf dem Server werden also folgende Komponenten zur ownCloud mit installiert:

  • nginx Webserver
  • PHP5
  • SQLite (Datenbank auf Dateibasis)
  • sowie diverse Pakete zum Performancegewinn

Nachdem man sich via http://www.raspbian.org/RaspbianInstaller mit den Raspbian-Installer ein Debian Weezy Grundsystem installiert hat, installiert man sich mit raspi-config ein sehr praktisches Konfigurationswerkzeug, um auf dem System ein paar grundlegende Einstellungen für das Gerät vorzunehmen.

sudo apt-get install raspi-config
sudo raspi-config
  1. change_locale zu „en_US.UTF-8“ für das komplette System (Ansonsten meckert ownCloud, dass es zu Fehlern bei Dateinamen mit Sonderzeichen kommen kann)
  2. memory_split auf „16“ MB einstellen. Dies ist die kleinst mögliche Einstellung. Die GPU bekommt somit 16MB.
  3. overclock auf „Medium“ 4. „Finish“ und danach die Frage nach dem Reboot mit „Yes“ beantworten.

Paketlisten aktualisieren

sudo apt-get update
sudo apt-get upgrade

Benutzer erstellen

sudo groupadd www-data
sudo usermod -a -G www-data www-data

Installation der Pakete

 sudo apt-get install nginx openssl ssl-cert php5-cli php5-sqlite php5-gd php5-curl php5-common php5-cgi sqlite php-pear php-apc curl libapr1 libtool curl libcurl4-openssl-dev php-xml-parser php5 php5-dev php5-gd php5-fpm memcached php5-memcache varnish

SSL Zertifikat erstellen (gültig für 1 Jahr)

sudo openssl req $@ -new -x509 -days 365 -nodes -out /etc/nginx/cert.pem -keyout /etc/nginx/cert.key
sudo chmod 600 /etc/nginx/cert.pem
sudo chmod 600 /etc/nginx/cert.key

nginx Webserver konfigurieren

sudo nano /etc/nginx/sites-available/default

Hier löscht man den kompletten Inhalt und fügt stattdessen den unten stehenden ein.
Darauf achten, dass man die IP-Adresse „192.168.XXX.XXX“ mit der des Raspberry Pi ersetzt.

server {
listen 80;
  server_name 192.168.XXX.XXX;
  rewrite ^ https://$server_name$request_uri? permanent;  # enforce https
}

server {
listen 443 ssl;
server_name 192.168.XXX.XXX;
ssl_certificate /etc/nginx/cert.pem;
ssl_certificate_key /etc/nginx/cert.key;
root /var/www;
index index.php;
client_max_body_size 1000M; # set maximum upload size
fastcgi_buffers 64 4K;


location ~ ^/owncloud/(data|config|\.ht|db_structure\.xml|README) {
  deny all;
}


location / {
  try_files $uri $uri/ index.php;
}

location @webdav {
  fastcgi_split_path_info ^(.+\.php)(/.*)$;
  fastcgi_pass 127.0.0.1:9000;
  fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
  fastcgi_param HTTPS on;
  include fastcgi_params;
}

location ~ ^(?.+?\.php)(?/.*)?$ {
  try_files $script_name = 404;
  include fastcgi_params;
  fastcgi_param PATH_INFO $path_info;
  fastcgi_param HTTPS on;
  fastcgi_pass 127.0.0.1:9000;
}
}

Danach in folgender Datei die Werte „upload_max_filesize“ sowie „post_max_size“ auf 1000M setzen.

sudo nano /etc/php5/fpm/php.ini
upload_max_filesize = 1000M
post_max_size = 1000M

Am Ende der Datei noch folgendes einfügen:

upload_tmp_dir = /srv/http/owncloud/data

Als nächstes muss folgender Ordner mit den dazugehörigen Rechten erstellt werden

sudo mkdir -p /srv/http/owncloud/data
sudo chown www-data:www-data /srv/http/owncloud/data

PHP konfigurieren

sudo nano /etc/php5/fpm/pool.d/www.conf

Hier ändert man folgende Zeile von:

listen = /var/run/php5-fpm.sock

zu

listen = 127.0.0.1:9000

Webserver und PHP neustarten

sudo /etc/init.d/php5-fpm restart
sudo /etc/init.d/nginx restart

ownCloud installieren
Als letztes wird ownCloud installiert. Folgende Befehle müssen abgearbeitet werden.

wget http://download.opensuse.org/repositories/isv:ownCloud:community/Debian_7.0/Release.key
apt-key add - < Release.key echo 'deb http://download.opensuse.org/repositories/isv:ownCloud:community/Debian_7.0/ /' >> /etc/apt/sources.list.d/owncloud.list
apt-get update
apt-get install owncloud

Nun lässt sich der Server im lokalen Netz aufrufen. In meinem Fall ist das https://192.168.1.104/owncloud. Als letztes muss nur noch ein Administratorkennwort und ein Benutzername festgelegt werden. Somit ist die Installation vollends abgeschlossen.

Der schnellste Weg, Adressbücher und Kalender in die eigene Wolke zu laden, führt über die Webanwendung von Owncloud, die Dateien im VCF- und ICS-Format importieren kann.

Bei Adressbüchern (.vcf) klappte der Import im Versuch allerdings nicht immer reibungslos. Bei einem Adressbuch, in dessen Feldern Doppelpunkte vorkamen, brach der Import leider ab. Im Zweifel muss man vor dem Import noch an den Daten feilen. Auch Gruppen ließen sich nicht importieren, da ownCloud sie als regulären Adressbuch-Eintrag interpretierte. Ein Fehler, der hoffentlich bald behoben wird.

Weiterführende Links:
Artikel bei iRights.info
Das Howto im RaspberryPi-Forum

USBIP auf einem Raspberry Pi starten

Innerhalb meiner Peergroup hatte die Tage jemand versucht, mit Hilfe der Linux-Software USBIP Geräte, welche an einem USB-Port hängen, auch für ein Netzwerk nutzbar zu machen. Im Gegensatz zu einem normalen Debian-Kernel für Standart-PC’s, sind die entsprechenden USBIP-Module aber für die ARM-Architektur im Kernel nicht enthalten. Und irgendwie scheint es prinzipiell wohl Probleme zu geben, die Treiber für den Kernel zu bauen. Dies trifft also nicht nur auf den Raspberry Pi, sondern auch so netter Embeded-Hardware wie der Dockstar. Nach ein bischen stöbern über die allseits bekannten Suchmaschienen bin ich aber hier auf eine – für’s erste funktionierende Lösung gestossen. Sie ist auf ein Debian Wheezy abgestimmt.

Als erstes sollte man sich vergewissern, dass man für sein Raspberry Pi sowohl den aktuellsten Kernel, als auch die neuen Firmware-Treiber und Module geladen hat. Dann wie folgt:

sudo apt-get install git
git clone git://github.com/raspberrypi/linux.git kernel
cd kernel
wget https://raw.github.com/raspberrypi/firmware/master/extra/Module.symvers
zcat /proc/config.gz > .config

Als nächstes öffnet man mit einem Editor die .config und fügt am Ende folgendes hinzu:

CONFIG_USBIP_CORE=m
CONFIG_USBIP_VHCI_HCD=m
CONFIG_USBIP_HOST=m
CONFIG_USBIP_DEBUG=n

Danach auf der Kommandozeile folgende Befehle absetzen:

make oldconfig
make LOCALVERSION=+ modules_prepare
make SUBDIRS=drivers/staging/usbip
sudo make SUBDIRS=drivers/staging/usbip modules_install
sudo depmod -a

Jetzt USBIP installieren:

sudo apt-get install usbip

Nun den Host-Treiber laden (um USB-Geräte teilen zu können)

sudo modprobe usbip-host

Zum Geräte auflisten:

sudo usbip list -l

Man sollte sich die Bus-ID merken, damit man das Gerät dann zum Teilen frei geben kann:

sudo usbip bind --busid 'BUSID'

Als Antwort kommt dann:

bind device on busid 'BUSID': complete

Für den Client wird dann folgendes ausgelöst:

sudo modprobe vhci-hcd
usbip list --remote 'pi ip'
sudo usbip attach --host 'pi ip' --busid 'BUSID'
lsusb

Syntax-Highlighting in vi abschalten

Ich bin ja eher ein schlichter Typ und mag es deshalb nicht, wenn etwas bei einem möglichst ergonomischen Arbeitsprozess anschreit. Dazu zählt das Syntax-Highlighting auf einem Kommandozeilenterminal. Und der Editor vim macht aber eben genau das standartgemäss unter einem Linux. Mit dem Befehl :syntax off im Kommandomodus lässt sich das Highlighting abschalten und mit :syntax on bei Bedarf wieder einschalten.

Will man dauerhaft auf dieses Feature verzichten, ändert man entsprechend die Zeile Syntax on in den Wert off um. Auf einem System mit root-Zugriff macht man das Idealerweise gleich in der globalen Konfigurationsdatei unter /etc/vim/vimrc. Hat man keinen vollen Administrationszugriff oder befindet sich unter einem Darwin-System, setzt man sich diese Option in seinem Heimverzeichnis in der Datei ~/.vimrc.

screen: „No more PTYs“ error

Auf einem Linux-Server, auf welchen ein Ubuntu 10.04 läuft, kam bei dem Versuch als eingelogter Benutzer eine screen-Session zu starten die Fehlermeldung ‚No more PTYs, Sorry, could not find a PTY‚. Als angemeldeter root-User funktionierte es hingegen einwandfrei.
Damit man als einfacher Benutzer auf dem Rechner screen dennoch benutzen kann, sollte man schauen, dass man sich in der Gruppe tty befindet und die entsprechenden Zugriffsrechte für /dev/pts und dem Verzeichnis /dev/ptmx richtig gesetzt sind.

Folgender Befehl löste dann das Problem:

mount -t devpts /dev/ptmx /dev/pts

Um das Pseudodateisystem automatisch zu mounten, ist am besten folgende Zeile in die /etc/fstab einzutragen:

/dev/ptmx /dev/pts devpts defaults 0 0