• <name>.jar – ganz klar, das ist die kompilierte gepackte JavaFx-Datei. Überraschend ist, sie unterscheidet sich von der Dateiendung überhaupt nicht von üblichen Java-Dateien – dazu später mehr.
• <name>.html – hier ist schon eine Beispieldatei, die zeigt, wie mans in den Browser einbindet – schön
• <name>.jnlp Auf diese Datei verlinkt man z.B. mit dem orangen Button, den man vielleicht auch schon von Java kennt, wenn man die jar mittels Download einfach starten will. Funktioniert mit JavaFx recht gut (zumindest meine Erfahrung)
• <name>_browser.jnlp – Die wird benutzt, wenn JavaFx direkt embedded im Browser laufen soll.

Netbeans richtet das schon entsprechend ein, wenn man bei project properties auf Run geht. Hier kann man auswählen zwischen:

• standard execution: als normale Desktop-Anwendung
• webstartexecution: Start mit einem Button auf der Webseite
• run in browser: brauch ich nicht weiter kommentieren
• run in mobile emulator: für Mobile Phone Apps und so… (übrigens auch sehr vielseitig in Netbeans)

Außerdem sollte man noch unter application eventuell self signed anklicken und die width und height ändern, falls nötig.

Das war alles? Nein, leider nicht. Wenn man eine ältere Netbeans Version benutzt, kann es passieren, das an mindestens einer Stelle ein / fehlt in der jnlp beim update-tag, es sollte so aussehen:

<update check="background"/>

Keine Ahnung, obs überhaupt Probleme bereitet, aber trotzdem sollte man nach Möglichkeit immer eine aktuelle Version benutzen

Dass man die Dateipfade eventuell in der html-Datei anpassen muss, sobald man die Files uploaded ist natürlich leicht ersichtlich. Leicht vergessen kann man aber Pfade, die noch in den JNLP-Dateien stehen:

<xml version="1.0" encoding="UTF-8"?>
    <jnlp spec="1.0+" codebase="http://meineseite.de/bla/bla/" href="app.jnlp">
    <information>
      <title>Titel</title>
      <vendor>Mein Name</vendor>
      <homepage href="http://meine.seite.de">
      <description>meine tolle App</description>
      <offline-allowed/>
(...)

Hier ist vor allem der Codebase-Tag wichtig, den Homepage-Tag sollte dann gleich mit setzen, und wenn man ordentlich ist über die anderen auch mal drüber schauen (Vendor, Description) – kann nicht schaden.

Vorrausgesetzt man hat das alles erledigt, sollte von der Sever-Seite eigentlich alles funktionieren. Probleme hat man aber trotzdem noch oft genug auf der Client-Seite, was mir so aufgefallen ist:

Windows XP

Normalerweise funktioniert das runterladen des “Browser-Plugins” wie immer recht problemlos, z.B. im Firefox. Wenn man hinter einem Proxy sitzt, siehts aber nicht mehr so gut aus, es wird versucht Zertifikate runterzuladen und lange Zeit passiert nichts, in Java-Konsole findet etwa so etwas:

Reading certificates from 341411 http://dl.javafx.com/javafx-rt-windows-i586__V1.2.0_b233.jar (...)

Dazu gibts auch schon einen Bug-Report.

Linux

Hatte ich auch häufig Probleme, dies bezog sich vor allem auf das Browser-Plugin. Denke das bezieht sich auf alle gängigen Browser. Wenn man Debian oder Ubuntu nutzt, sollte folgendes helfen:

aptitude install sun-java6-plugin

Wem das zu einfach ist, oder wer damit Probleme (verschiedene Java Versionen, Probleme mit 64/32 bit etc.) der kann sich das libjavaplugin_oji.so auch selber zurecht pfuschen, schön dokumentiert bei SUN

OpenSolaris

Ok, saß zufällig an einem OpenSolaris, und dachte mir ich teste es mal. Ich hätte so ziemlich alles erwartet. Aber DAS war echt der Hammer: Nicht mal das Plugin musst ich noch installieren, lief sofort problemlos. Daumen hoch OpenSolaris – ein oft unterschätztes, hochwertiges Betriebssystem. Hoffen wir mal, dass sich das mit Oracle nicht ändert.

java -jar macht ClassNotFoundException

Ja, wie schon oben erwähnt sind die JavaFx-Files ja genau so benannt mit die Java-Files, da ist java -jar aber trotzdem falsch. Am einfachsten ist natürlich die html lokal zu öffnen und dann den Launch dort machen . Richtig desktop-mässig gehts natürlich auch, mit javafx appName.Main – dazu muss natürlich der javafx Path usw. gesetzt sein. Es gibt auch mit ein langes Java-Äquivalent mit java -cp PfadZuJavaFx (…).

Acer Aspire One

Auf mein neues Acer Aspire One wollt ich natürlich direkt mal ein Linux haben. Das olle Xp hab ich mir gar nicht mal mehr angeschaut. Hab mich nach kurzer Recherche ziemlich schnell für Ubuntu Netbook Remix entschieden.

Da das kleine Gerät natürlich kein CD-ROM Laufwerk hat, muss der Netbook Remix über ein bootbaren USB-Stick installiert werden. Die Anleitungen auf der Ubuntu Seite fand ich etwas konfus, obwohl es eigentlich ganz einfach ist:

• Iso Image Ubuntu Netbook Remix runterladen
• In einem verfügbaren Ubuntu den USB-Creator starten, ISO-Image auswählen, USB-Stick auswählen, Rest geht von selbst
• USB-Stick ins Netbook, starten, installieren

Screenshot Oberfläche Netbook Remix

Ok, ein paar Pitfalls gabs bei mir noch:

In Kubuntu hatte ich immer Probleme, wenn ich den usb-creator von der Konsole aus gestartet hab, das Programm konnte dann den USB-Stick nicht mounten. Lösung war einfach den USB-Creator (zu deutsch USB Startmedien Ersteller) aus dem KDE-Menü starten. Ich vermute mal ein kleines Problem, dass mit der Gnome Herkunft des Tools und Root-Rechten zusammenhängt, was sich in KDE irgendwie beißt.

Das nächste kleinere Problem: Wenn man einmal mit dem Stick gebootet hat, z.b. “Ubuntu ausprobieren” und / oder die Installation wieder abgebrochen hat, ist das Image eventuell nicht mehr brauchbar, weil wohl zwischendurch irgendwelche Sachen drauf geschrieben, die beim nächsten Boot Fehlermeldungen verursachen. Lösung ist natürlich ganz einfach: Nochmal den USB-Creator

Dann noch ein Hinweis zum Booten: Im Bios (F2) muss beim Acer Aspire One die Reihenfolge der Devices geändert werden, so dass als erstes beim USB-Anschluß nach einer bootbaren Partition gesucht wird.

Der Rest verlief absolut problemlos, WLAN, Webcam, Mikro – läuft alles Out-of-the-Box. Und sehr positiv find ich auch den Aufbau der Oberfläche, sehr intuitiv und übersichtlich, und selbst bei dem kleinen Display hat man bei den meisten Programmen genug Platz.

Update:

Und gerade erst bei einer Präsentation ausprobiert – zweiten Monitor (bzw. Beamer) anschließen klappt auch problemlos!

Systems and/or methods are described that enable a user to elevate his or her rights. In one embodiment, these systems and/or methods present a user interface identifying an account having a right to permit a task in response to the task being prohibited based on a user’s current account not having that right.

Na… das is doch sudo! Oder sudo mit ner GUI, dann halt kdesu oder gksudo! Hätte ichs nicht selber gesehen, ich würds mal wieder für einen Scherz halt. Aber diese Trivialpatente sind langsam echt nich mehr zu lachen. Sudo benutzt Linux schon seit Jahrzehnten – und Microsoft verkaufts quasi wieder als eigene, neue Idee?

Kurios ist auch, dass (wie ich in auf der zitierten Seite nachlesen konnte) es angeblich früher ein ähnliches Linux-Tool namens runas gegeben hat, und auch genau den gleichen Namen trägt wie das Microsoft-Tool zu dem das Patent gehört.

Tja, wie soll man bei den Trivialpateten  noch glauben können, dass das Patentwesen dazu dient Inventionen zu fördern?

deb http://ftp.de.debian.org/debian/ sid main non-free contrib
deb-src http://ftp.de.debian.org/debian/ sid main non-free contrib

Die testing Quellen kann man einfach drin lassen. Als nächstes legt man eine /etc/apt/preferences an (oder editiert sie, falls sie schon existiert):

Package: *
Pin: release a=testing
Pin-Priority: 800
 
Package: *
Pin: release a=unstable
Pin-Priority: 300

Damit sagt man aptitude quasi, dass er Quellen aus Debian testing bevorzugen soll, und nur in Ausnahmefällen aus unstable installiert wird. Also dann noch ein aptitude update und dann den aktuellen Kernel raussuchen, in meinem Fall der 2.6.30er, und installieren. Fertig.
Die sources.lst und so kann man ruhig so lassen. Vielen Dank noch mal an JHR der mir das telefonisch alles so toll erklärt hat!

Mit dieser Release-Politik reagiert man vermutlich auf die immer länger werdenen Releasezyklen. Debian Lenny war ursprünglich für September 2008 geplant, jedoch wurde es erst fast ein halbes Jahr später (Februar 2009)  freigegeben. Schon früher gab es häufiger Kritik, dass Debians stables oft veraltet seien und zu selten neue Releases stattfanden. Hier findet eine Annäherung an die Release Politik von Ubuntu statt, die etwa halbjährlich ein neues Release rausbringen. Debian Anhänger schätzen jedoch im Allgemeinen die längeren Releasezyklen von Debian, wenn hier im Gegenzug Bugs sorgfältiger behoben werden und mehr Stabilität gewährleistet werden kann.

Ich persönlich würde mich zwar freuen, wenn Debian Releases etwas öfter und regelmässiger stattfinden, aber möchte ich dies nicht zum Preis von reduzierter Stabilität haben. Wenn mir die Akutualität so sicher wäre, wäre ich auch schon längst zu Ubununtu gewechselt. Naja, mal sehen was draus wird.

Der Freeze von Debian Lenny wird dann früher stattfinden als geplant, nämlich schon im Dezember diesen Jahres.

EDIT:

In einem Heise Artikel ist inzwischen zu lesen, dass das Debian Team die Mitteilung aufgrund der wachsenden Kritik abgeschwächt hat und die festen Freeze-Zyklen nur noch als Vorschlag versteht, der noch diskutiert werden soll. Naja, irgendwie hab ich mir schon sowas gedacht…

Ports in Windows XP freigeben: Systemsteuerung -> Windows Firewall -> Ausnahmen -> Port TCP 16001 und beliebigen Namen eingeben, fertig.

Ubuntu Cola

Komm ich grad nach Hause, steht ne Flasche Cola auf meinem Schreibtisch. Hat mir mein Bruder mal wieder was witziges aus Schweden mitgebracht, Ubuntu Cola. Naja, es zwar hat zwar den gleichen Namen wie eine bekannte Linux Distribution, aber die stehen wohl in keiner Verbindung. Aber der Name weißt schon drauf hin, was es sein könnte, nämlich ein Fairtrade Produkt. Aber halt genau das richtige für mich, ein Ubuntu mit reichlich Koffein und Zucker aus Malawi und Zambia – gefällt mir

Aber diese so genannten Lock-In-Effekte bin ich ja mittlerweile vom großen T gewöhnt. Ich erinnere mich auch noch an Zeiten, wo ich bei T-Online für Spamschutz meiner E-Mailadresse ein kostenpflichtiges Zusatzpaket hätte ordern müssen – währrend dieser Service schon von fast allen kostenlosen E-Mailanbieter in der Grundausstattung drin war. Und auch mit Pop-Mail hab ich bei dem großen T so meine Erfahrungen gemacht. Denn wenn ich mit nem anderen Anbieter online bin, brauch ich auch das E-Mail-Zusatzpaket, damit ich meine E-Mail per pop abrufen kann. Unglaublich, da hat man schon einen Vertrag bei den Jungs und muss immer noch für Dinge, die sonst umsonst gibt, zu zahlen. Aber man kann die Jungs auch austricksen, zumindest wenn man irgendwo einen entfernten Rechner stehen hat, der mit T-Online im Netz ist. Die Lösung heißt ssh-Tunnel.

Einstellungen für ssh-Tunnel im E-Mail-Programm

Zunächst muss man die IP des entfernten T-Online Rechners wissen, falls diese nicht fest ist, bietet es sich an, ein dyn-alias einzurichten. Dann stellt einfach anstatt popmail.t-online.de in seinem Email-Programm als Server localhost ein, und nimmt einen freien Port, z.B. 8110.

Nun einen ssh-Tunnel aufbauen mit:

ssh -L 8110:popmail.t-online.de:110 benutzer@meinTOnlineRechner.de

wobei 8110 der Port ist, den man im E-Mail-Programm eingestellt und benutzer@meinTOnlineRechner.de der Benutzername und IP / Adresse des entfernten Rechner ist. Das kann man sich zum Beispiel auch als alias in der bashrc anlegen, falls man es häufiger nutzen möchte.

Wenn man nun mit seinem E-Mail Programm versucht die E-Mails abzurufen, werden diese versucht über localhost, also dem eigenen lokalen Rechner, abgerufen auf Port 8110. Der ssh-Tunnel leitet Port 8110 aber weiter auf den entfernten Rechner und dieser wieder spricht dann popmail.t-online auf Port 110 an.

Mag sein, dass es weniger umständlich und schneller ist, sich eine neue E-Mailadresse bei einem anderen Anbieter zu besorgen – aber wenns ums Prinzip geht und hin und wieder noch E-Mails auf der T-Onlineadresse ankommen, find ich das keine schlechte Lösung Und ich schätze mit ähnlichen Mitteln lassen sich auch auf modernen Mobiltelefonen sperren von VoIP-Programmen umgehen…

Denn auch auf meinem alten Rechner im Keller, den ich als kleinen Webspace und ähnliches nutze, habe ich meine Festplatte mit dm-crypt verschlüsselt – wie sich das  als revolutionärer aufsässiger verantwortungsbewusster Staatsfeind Benutzer  gehört (Anleitungen dazu gibts ja genug im Internet). Nur das Passwort, ca. 12stelliger Salat aus Buchstaben und Zahlen – wies immer sein sollte im Idealfall -, hab ich innerhalb eines halben Jahres höchstens 3 oder 4 mal benutzt, so konnte ich mich dann beim nächsten Reboot leider nicht mehr erinnern.

Der Zettel, auf dem ich es mir notiert hatte – ich wusste es gab ihn mal – konnte ich besten Willens nicht wiederfinden, vermutlich war er schon vor langer Zeit in den Papierkorb gelandet. Nach reichlich Überlegen und Grübeln (was sich über einige Tage hinstrecke) war ich mir aber sicher, den Großteil des Passworts bis auf ein paar Ziffern am Ende wieder zu wissen. Aber bis hier hin Sackgasse. Naja, und ein Hacker bin ich auch nicht, also mal das Web nach möglichen Tools abgesucht – Fehlanzeige. Also selber mal rumbrobiert. Die Lösung war aber mehr als einfach, schon allein weil cryptsetup das Passwort über eine einfache Pipe aktzeptiert:

#!/bin/bash
known="bekannterTeil"
for i in $(seq 9999); do
    passtest=$known$i
    echo Trying $passtest
    echo $passtest | cryptsetup luksOpen /dev/hda8 hda8_crypt
    if [ -n "$(ls /dev/mapper/ | grep crypt)" ]
        then    echo Passwort gefunden! $passtest
                exit 0
    fi
done

Das Skript hängt einfach nur an den bekannten Teil des Passworts eine Nummer an und testet das Passwort, falls nach dem Aufruf ein Mapper-Device mit “crypt” existiert sind wir fertig – und sonst halt alle Nummern ausprobieren. Bestimmt kann mans noch schöner machen, oder mit Python oder Perl ganz tolle RegExp durchprobieren und nicht einfach nur statisch ne Nummer dranhängen. Aber mir gehts hier nich drum, irgendwelche Hackertools zu basteln. Für mich hats gereicht, nach ein paar wenigen Stunden (cryptsetup erlaubt bei Standardeinstellung nur 1 Versuch pro Sekunde) hatte ich mein Passwort wieder .

Und was lernt man aus der Geschichte?

1. Selbst die beste Verschlüsselung nützt einem nichts, wenn man ein schwaches Passwort hat, schon allein die Kenntnis von der Länge und Teilen des Passworts und /oder genutzte Zeichen ermöglichen eine sehr schnelle Brute-Force suche! Gleiches gilt natürlich für Passwörter, die im Duden stehen. Und Passwort-Generatoren gibts ja genug im Internet…
2. Die alte Idee vom Verbot von Hacker-Tools würde dazu führen, dass die oben genannte Schleife ebenso illegal ist. Lächerlich
3. In Zukunft werd ich mehr drauf achten, mir wichtige Passwörter an einem sicheren Ort zu notieren.

Über die Möglichkeit eines Livestreams hatte ich mir auch Gedanken gemacht, aber der technische Aufwand war mir dann doch zu hoch – der webserver muss schließlich auch alles unterstützen und gescheite Programme braucht der Mensch.

Nunja, als nächstes musste das ganze nur noch ins www. Auch hier habe ich lange gesucht nach kostenlosen fertigen Lösungen. Die Auswahl war zwar groß, aber die Anzahl der brauchbaren Lösungen war leider nicht so wie ich erwartet hatte. Letztendlich bin ich doch bei einem recht simplen Javascript gelandet von cowboyscripts.org. Das Script lädt das Bild in festgelegten Abständen einfach neu. Naja, ich gebe zu, dass Script is schon ein paar Jahre älter, aber es tut seinen Dienst. Und mehr wollte ich auch nicht.

Die letzte Hürde war nach einer einfachen Konfiguartion des scripts und dem dazughörigen html-Template die Integration in den Blog. Nach ein bißchen Rumprobieren war die Lösung ganz einfach – mittels eines iframes, der die html mit der webcam included.