joachim
This user hasn't shared any biographical information
Posts by joachim
Tunneling AFP durch SSH
Sep 16th
Mit folgenden Befehlen kann man das angebotene Apple File Protocol eines entfernten Servers in das lokale Netzwerk befördern.
SSH ermöglicht eine sichere Terminal Verbindung zu einem Host-Rechner. So kann man auch mittels Port Forwarding auf einen Rechner zugreifen, der in einem Fremden Netzwerk, hinter einem Router / Firewall / etc. steht.
Auf diesem Host-Rechner muss der SSH Service laufen – wer hätte es gedacht, die Synology DiskStation bietet eben diesen Service. Aktivierbar unter Netzwerkdienste -> Terminal -> SSH Dienst aktivieren.
Außerdem bietet die DiskStation noch das AFP (unter Gemeinsame Dateien -> Win/Mac OS -> Mac Dateidienst aktivieren).
Befindet man sich nun Unterwegs/in einem fremden LAN und möchte auf die heimische DiskStation zugreifen, bietet es sich an, diese per SSH anzusprechen und das AFP hindurch zu tunneln. Anschließend kann auf die DiskStation zugreifen, als befände man sich im gleichen Netzwerk und das schöne ist, die Verbindung ist über SSH gesichert.
Folgende Befehle sorgen dafür, dass die entfernte DiskStation auf dem lokalen Rechner erreichbar wird.
dns-sd -R DiskStation _afpovertcp._tcp . 12345 > /dev/null & ssh -gNL 12345:127.0.0.1:548 root@remote.host.com
Erklärung:
Der Erste registriert den AFP Dienst unter dem Namen DiskStation über den Port 12345. Es wird so ein AFP Dienst angekündigt, der vom Dienst aus dem entfernten Netzwerk noch bedient werden muss.
Die Parameter:
- g sorgt dafür, dass der entfernte Host auf den lokal freigegebenen Port (12345) zugreifen darf – somit kann der entfernte Server seinen AFP Dienst durch den SSH-Tunnel über den Port 12345 bekannt machen.
- N bewirkt, dass nur die Tunnelfunktion genutzt wird, keine Konsoleneingabe möglich.
- L bewirkt das eigentliche Tunneln. Hier wird der lokale Port 12345 auf den entfernten Rechner auf 548 gemappt (wenn man statt 127.0.0.1 eine andere Adresse angibt, so könnte der SSH Dient auf einem anderen Rechner laufen, wie AFP).
- Als letztes wird angegeben, dass die SSH Verbindung über den Benutzer root am remote.host.com hergestellt wird.
Kleine Ergänzung:
Wer das ganze noch gerne ohne Passwortabfrage hätte, ist folgender Artikel im Wiki wärmstens empfohlen:
http://wiki.joachimschuster.de/index.php/SSH_ohne_Passwortabfrage
Ruby on Rails und Redmine auf Synology DiskStation
Sep 15th
Vor einigen Monaten versuchte ich Ruby on Rails auf der Synology DS106 zu installieren um anschließend das Projektmanagement Tool Redmine darauf laufen zu lassen.
Da das Ergebnis leider nur die Information war, dass die DS106 für Ruby einfach hoffnungslos unterdimensioniert ist, musste die Sache erst mal ruhen.
Bis jetzt endlich die neue DS210+ mit 512MB RAM und 1 GHz CPU zur Verfügung stand. Den kleinen Leistungsunterschied (vgl. 32MB RAM 266MHz) merkt man dann doch umgehend 
Da die Installation nun erfolgreich durchgeführt werden konnte, habe ich die Anleitung noch mal überarbeitet und in Englisch verfasst.
Am Kniffligsten war nicht das Einrichten selbst, sondern den Dienst anschließend beim Booten automatisch starten zu lassen.
Dabei stellte sich heraus, dass zwei Umstände zu Problemen führten:
- Ruby möchte beim Ausführen ins Home-Verzeichnis des ausführenden Benutzers das Verzeichnis .gem (mit Dateien etc.) anlegen
- Redmine über Webrick gestartet will im Verzeichnis, in dem der Webservice ausgeführt wird, ein tmp-Verzeichnis erstellen.
Der erste Punkt kann dadurch behoben werden, dass die home-Verzeichnisse der Benutzer aktiviert werden. Dazu den Benutzer-home-Dienst unter Berechtigungen -> Benutzer -> Benutzer-Home aktivieren.
Der zweite Punkt kann durch das Wechseln in den Ordner, in dem der Redmine Service liegt behoben werden. Von dort aus kann dann der Dienst gestartet werden, da der Benutzer redmine darin schreibrechte hat.
Universal App für iPad und iPhone/iPod Touch
Jun 28th
Mit der Entwicklung für das iPad wurde das SDK auf 3.2 gehoben. Um das iPhone vom iPad unterscheiden zu können, sieht Apple folgende Abfrage vor:
if (UI_USER_INTERFACE_IDIOM() == UIUserInterfaceIdiomPad)
{
// iPad mit iPhone 3.2 oder neuer.
} else {
// Das Gerät ist ein iPHone oder iPod touch.
}
Das userInterfaceIdiom steht aber erst unter 3.2 und neuer zur Verfügung, sodass die o.g. Abfrage auf Geräten mit iPhone OS kleiner 3.2 zu einem Fehler führt.
Nutzt man zur Kontrolle ein altes Xcode (z.B. 3.1.4) so kann man sehen, dass dieser Code unbekannt ist und schon zur Compilezeit Fehler wirft.
Um die Unterscheidung auch in 3.2 treffen zu können, bietet es sich an, die Abfrage durch ein ifdef zu beschränken. Abhängig davon, ob die Funktion im Framework verfügbar ist, wird der enthaltene Code ausgeführt oder nicht.
BOOL iPad = NO;
#ifdef UI_USER_INTERFACE_IDIOM
iPad = (UI_USER_INTERFACE_IDIOM() == UIUserInterfaceIdiomPad);
#endif
if (iPad) {
nibName = @"MainView-iPad";
} else {
nibName = @"MainView";
}
Der Trick ist also, davon auszugehen, dass man per Default nicht auf einem iPad läuft. Sollte man sich auf einem System befinden, das 3.2 oder höher (z.B. iOS 4) läuft, so wird die Auswertung vorgenommen. Im Falle eines Gerätes mit iOS 4 würde die Auswertung immernoch NO (False) ergeben, da es sich nicht um ein iPad handelt. Nur wenn es wirklich ein iPad ist, wird auch das nib-File für das iPad geladen.
Somit läuft der Code auf allen Geräten ab 3.0.
