Port-Weiterleitung mittels SSH

Ich hat­te soeben das Pro­blem, dass ich gern auf einen Dienst zuge­grif­fen hät­te, der auf einer ent­fern­ten Maschi­ne auf Port 443 läuft. Außer­halb des eige­nen Net­zes, also für IP-Adres­sen, die nicht im glei­chen Netzsseg­ment lie­gen, wur­de der Zugriff auf Port 443 aber gesperrt. Über eine SSH-Ver­bin­dung am Ter­mi­nal mit Lynx zu arbei­ten fiel auch aus, da der Web­ser­vice mas­si­ven Ein­satz von Java­Script macht und ohne die­ses qua­si nicht benutz­bar ist.

Also muss­te eine Mög­lich­keit her, trotz der Ein­schrän­kung auf die­sen Ser­vice zuzu­grei­fen. Eine loka­le Port­wei­ter­lei­tung mit­tels SSH erbrach­te den gewünsch­ten Effekt. Hier­für wird eine Art Daten­um­lei­tung ein­ge­rich­tet, mit deren Hil­fe man die Anfra­ge- und Ant­wort­pa­ke­te an den jeweils zustän­di­gen Port umlei­tet.

https://gist.github.com/481534

Der Befehl ssh soll­te bekannt sein. Die Opti­on -L bin­det einen loka­len Port an einen Remo­te-Port, wie auch im Bei­spiel zu sehen ist. Über [email protected] mel­det man sich dann mit gül­ti­gen Zugangs­da­ten an der Maschi­ne an, auf der der Ser­vice läuft.

Kon­kret habe ich in mei­nem Fal­le den loka­len Port durch 14500 ersetzt, den Remo­te-Port durch 443. SSH baut die Ver­bin­dung und damit auch den Tun­nel auf, et voi­là, schon kann man über den Brow­ser mit­tels

http(s)://localhost:14500

auf den Web­ser­vice zugrei­fen. Die Ein­schrän­kung im Ziel­netz, dass Port 443 nach außen nicht erreich­bar sein darf ist somit umgan­gen.

Kostenlose GTD-App hosted by Klose IT

Tracks-logo-dark

Ihr sucht nach einer guten, über­all ver­füg­ba­ren GTD (Get­ting Things Done)-Applikation? Hört auf zu suchen. Ich habe soeben auf mei­nem Ser­ver die sehr gute Web-Appli­ka­ti­on Tracks instal­liert und für die All­ge­mein­heit frei­ge­ge­ben. Der Log­in erfolgt über Ope­nID, es geht also kaum unkom­pli­zier­ter. Jeder, der bei­spiels­wei­se einen Goog­le- oder Yahoo-Account besitzt, hat auch eine Ope­nID. Der­zeit ist die Appli­ka­ti­on nur in eng­li­scher Spra­che ver­füg­bar, aber das Ent­wick­ler-Team arbei­tet an einer loka­li­sier­ten Fas­sung. Ich wer­de die deut­sche Fas­sung zur Ver­fü­gung stel­len, sobald sie fer­tig ist.

Gehosted wird die Appli­ka­ti­on mit Ubun­tu 10.04 x64, als App­li­ca­ti­on-Ser­ver für die­se Rails-Anwen­dung ver­wen­de ich Uni­corn.

Bildschirmfoto_2010-07-11_um_13

Und nun, viel Erfolg und Spaß beim Selbst-Manage­ment. Zur Start­sei­te geht es hier ent­lang. Die Mobil-Ver­si­on (bspw. für iPho­ne und iPod touch) gibt es hier.

Die Krux mit den alten Browsern

Bildschirmfoto_2010-07-08_um_15

Wenn man eine neue Web­site erstel­len möch­te, wie ich es in den letz­ten Tagen mal wie­der getan habe, steht man immer wie­der vor der Ent­schei­dung, ob man auch älte­re Brow­ser­ver­sio­nen voll­stän­dig unter­stüt­zen möch­te. Dass der Inter­net Explo­rer 6 nicht mehr zu die­ser Rie­ge gehört, dar­über dürf­ten sich nahe­zu alle Web­de­si­gner einig sein, aber was ist mit den Ver­sio­nen 7 und 8 des Brow­sers aus Red­mond? Und wie steht es um die älte­ren Ver­sio­nen von Fire­fox, Ope­ra, Chro­me und Safa­ri?

Mei­nem Kennt­nis­stand nach ist bei vie­len opti­schen Schman­kerln, wie bspw. dem text-shadow, nur der Inter­net Explo­rer wirk­lich kri­tisch. Alle ande­ren Brow­ser, allen vor­an die Web­kit-Brow­ser Safa­ri und Chro­me, haben damit schon seit Ewig­kei­ten kei­ne Schwie­rig­kei­ten mehr. Ich weiß, der CSS3-Stan­dard ist noch gar kei­ner, da er offi­zi­ell noch nicht ver­ab­schie­det wur­de. Blöd ins­be­son­de­re des­we­gen, weil man für vie­le der CSS3-Attri­bu­te brow­ser­spe­zi­fi­sche Prä­fi­xe ver­ge­ben muss, was die erfolg­rei­che Vali­die­rung eines CSS3-Style­she­ets ver­hin­dert. Wenn ich mich recht ent­sin­ne, war bspw. der text-shadow mitt­ler­wei­le auch ohne Prä­fix unter den Web­kit-Brow­sern und Ope­ra nutz­bar, Fire­fox 3.6 besteht wei­ter­hin auf das Prä­fix. Mit der Beta des Fire­fox 4 habe ich es noch nicht getes­tet. Aber gut, wenn mal der eine oder ande­re Effekt nicht ange­zeigt wird, bricht einem das nicht gleich die Bei­ne, auch schlech­te und alte Brow­ser stel­len die Sei­te wenigs­tens dar.

Anders sieht es mit der Ver­wen­dung von HTML5 aus. Mei­ne Sei­te weist als DOCTYPE HTML5 auf. Ver­wen­den tue ich aber kei­nen der neu­en HTML5-spe­zi­fi­schen Tren­ner wie <arti­cle>, <sec­tion>, <hea­der> oder <foo­ter>, da, wenn der Brow­ser gar kein HTML5 ver­steht, die Sei­te schlicht und ergrei­fend gar nicht oder voll­stän­dig falsch ange­zeigt wird. Ich weiß, es gibt Java­Script-basie­ren­de Hacks, die das Pro­blem behe­ben, aber was ist, wenn der Benut­zer auch noch zusätz­lich Java­Script deak­ti­viert hat :-D? Wirk­lich scha­de, dass ich kein HTML5 ver­wen­den “durf­te”, ich hät­te es zu gern getan. Von den Java­Script-basie­ren­den Hacks hal­te ich aber nicht viel. Die rest­li­chen Scripts, die in mei­ner neu­en Sei­te ein­ge­bun­den sind, sind von eher unkri­ti­scher Natur. Das jQue­ry-Plugin Scroll­To erzeugt einen wei­che­ren Scroll­vor­gang als das nor­ma­le, Anchor-basie­ren­de Scrol­len und Fan­cy­box zeigt die Bil­der schick im Groß­for­mat an. Aber wenn die­se bei­den Scrip­te aus­ge­schal­tet sind, ist es auch egal.

Posi­tiv über­rascht war ich, dass das Ein­bet­ten von Fonts mitt­ler­wei­le (fast) tadel­los funk­tio­niert. Ein­zig und allein die Mobil­ge­rä­te zei­gen die ein­ge­bet­te­ten Fonts nicht an, so wenigs­tens gese­hen auf mei­nem iPho­ne und einem iPad. Der Inter­net Explo­rer kann das, oh Wun­der, schon seit Ewig­kei­ten, näm­lich seit der Ver­si­on 4, wenn auch mit einem spe­zi­el­len Font-For­mat, EOT (Embed­ded Open Type). Alle ande­ren Brow­ser mamp­fen brav mei­ne TTF- und OTF-Datei­en. Bis­her steht aber noch ein Test mit Alt-Brow­sern aus, getes­tet habe ich wirk­lich bis­her nur mit aktu­el­len Brow­sern auf mei­nem Mac. Wobei mir gera­de auf­fällt, dass ich die EOT-Ver­sio­nen mei­ner bei­den Fonts noch gar nicht erstellt und ein­ge­bun­den habe. Soll­te ich wohl mal flott nach­ho­len.

Da wir gera­de beim The­ma sind, hier ein klei­nes Bei­spiel für einen gül­ti­gen Ein­trag einer @font-face-Deklaration in einer CSS-Datei:

https://gist.github.com/468010

Die in die­sem Bei­spiel ver­wen­de­te Schrift, die ich dann doch nicht auf mei­ner Sei­te ver­wen­det habe, habe ich im Übri­gen bei The League of Mova­ble Type gefun­den. Eine wei­te­re sehr schö­ne Quel­le für offe­ne Fonts ist Font Squir­rel, die auch die Schrif­ten von The League of Mova­ble Type anzei­gen. Um die Schrif­ten von TTF in EOT zu bekom­men, habe ich den ttf2eot-Kon­ver­ter ver­wen­det. Die Kon­ver­tie­rung mei­ner OTF-Schrift ins EOT-For­mat hat der Online Font Con­ver­ter für mich über­nom­men. Ent­spre­chend der zuvor gezeig­ten Nota­ti­on kann die Schrift nun ganz regu­lär über eine font-fami­ly-Anwei­sung ver­wen­det wer­den.

Wie hal­tet ihr es mit der Ver­wen­dung von CSS3, HTML5 und sons­ti­gem neu­mo­di­schem Schnick­schnack? Ver­wen­den oder abwar­ten?

Sie ist online

Die letz­ten zwei Tage habe ich nun damit ver­bracht, das längst über­fäl­li­ge Rede­sign mei­ner geschäft­li­chen Home­page zu gestal­ten. Unter www.klose-it.de dürft ihr das Design-Meis­ter­werk (*räus­per*) begut­ach­ten. Für Kri­tik und Ver­bes­se­rungs­vor­schlä­ge bin ich natür­lich zu haben. Im glei­chen Atem­zu­ge habe ich auch mei­nen Fir­men­na­men, da er offi­zi­ell ohne­hin nir­gend­wo ein­ge­tra­gen ist, von Klo­se IT-Ser­vice auf Klo­se IT ver­kürzt. Passt nun bes­ser zum Domain­na­men und liess sich irgend­wie auch bes­ser in ein neu­es Logo ver­bas­teln.