Seiten

Sonntag, 20. Juli 2014

Kabelanschluss: Reconnect mit FritzBox hinter Kabelmodem

Da ich nun stolzer Besitzer eines Kabelanschlusses bin und auch wie vorher bei DSL einen Reconnect durchführen wollte, stellte ich fest das das nicht ganz so trivial wie vorher ist. Nach ein bisschen Recherche hatte ich zumindest die grobe Funktionsweise raus:
  1. Mac-Adresse des Routers ändern
  2. Kabelmodem neustarten
Klingt eigentlich ganz einfach, dachte ich... Mein Kabelmodem ist ein Scientific Atlanta (Cisco) EPC2203, welches vor einer FritzBox 7570 steckt. Nach mehreren erfolglosen Google-Anfragen konnte ich keine passende Lösung für mein Problem finden, also beschloss ich mir selbst etwas zu schreiben.
Meine Voraussetzungen sind eigentlich ganz einfach:
  • Skript zur Einbindung in unterschiedlichen Programmen, also kein Kompilat
  • Skript muss größtenteils mit Standard-Linux-Befehlen funktionieren
  • Keine modifizierte oder erweiterte Firmware der FritzBox
So weit so gut, der Befehl für das Neustarten des Modems war schnell im Netz gefunden:

curl http://192.168.100.1/goform/gscan -d SADownStartingFrequency=687000000

Funktionierte auf Anhieb, jedoch hat man da noch keine neu IP, es fehlt ja noch das Ändern der Mac-Adresse. Meine FritzBox bietet über die Oberfläche eine Möglichkeit die MAC zu ändern, welche komischerweise nicht funktioniert. Zumindest bleibt die MAC nach dem Übernehmen nicht gespeichert. Egal, da die Box ja auch einen Zugang über telnet anbietet mit dem man dies auch bewerkstelligen kann. Die dafür verantwortliche Datei nennt sich Ar7.cfg und muss bearbeitet werden. Diese Datei befindet sich unter /var/flash auf der Box und es müssen zwei Sachen bearbeitet werden:

  • enable_mac_override muss auf yes gesetzt werden, damit die Adresse überschrieben werden kann
  • macdsl_override muss auf die neue MAC gesetzt werden

telnet fritz.box

Da die ar7.cfg nicht direkt bearbeitet werden kann muss diese erst in das tmp-Verzeichnis der Box kopiert werden und wird dann später wieder zurückkopiert. Nach zahllosen Versuchen mit den begrenzten Befehlssatz der Box um meine Anforderungen zu erfüllen, kam ich dann letztendlich zu dieser Lösung:

cat /var/flash/ar7.cfg > /var/tmp/ar7.cfg
sed -i '/enable_mac_override/cenable_mac_override = yes;' /var/tmp/ar7.cfg
sed -i "s/\(macdsl_override = .*:\)\(.*\);$/\1$(cat /dev/urandom | tr -cd 'A-F  0-9' | head -c 2);/" /var/tmp/ar7.cfg
cat /var/tmp/ar7.cfg > /var/flash/ar7.cfg
exec /etc/init.d/rc.net reload

Zur zeilenweisen Erklärung :
Zeile 1:
Das vorher angesprochene Kopieren der Datei in den temporären Ordner
Zeile 2:
Es wird die Zeile mit enable_mac_override gesucht und - unabhängig von deren Inhalt wird diese mit enable_mac_override = yes; überschrieben.
Zeile 3 (die hat mit Abstand am längsten gedauert ;) ):
Es wird nach macdsl_override gesucht und der letzte Teil der MAC-Adresse ausgelesen. Dieser wird mit einer hexadezimalen Zufallszahl aus /dev/urandom ersetzt. Danch wird die ganze Zeile in die ar7.cfg zurückgeschrieben.
Zeile 4:
Die ar7.cfg wird wieder an ihren Ursprungsort kopiert
Zeile 5:
Damit die Einstellungen übernommen werden, wird nun noch die Netzwerkkonfiguration der FritzBox neu eingelesen.

Nachdem das nun funktioniert hat bleibt noch die Herausforderung das ganze per Skript auszuführen. Leider kommt man hier mit bash nicht wirklich weit und muss auf expect ausweichen. In den meisten Distributionen ist dies schon vorinstalliert. Hiermit ist es möglich interaktive Terminalsitzungen - wie bspw. telnet -  auszulagern, Befehle abzusetzen und bestimmte Ausgaben zu überprüfen.
Das resultierende Skript sieht dann so aus:

#!/usr/bin/expect

spawn telnet fritz.box
expect "password: "
send "MySecretPasswordReplaceWithYourOwn\n"
expect "#"
send "cat /var/flash/ar7.cfg > /var/tmp/ar7.cfg\n"
expect "#"
send "cat /var/tmp/ar7.cfg | grep overr\n"
expect "#"
send "sed -i '/enable_mac_override/c\enable_mac_override = yes;' /var/tmp/ar7.cfg\n"
expect "#"
send "sed -i \"s/\\(macdsl_override = .*:\\)\\(.*\\);$/\\1\$(cat /dev/urandom | tr -cd 'A-F0-9' | head -c 2);/\" /var/tmp/ar7.cfg\n"
expect "#"
send "cat /var/tmp/ar7.cfg > /var/flash/ar7.cfg\n"
expect "#"
send "cat /var/flash/ar7.cfg | grep overr\n"
expect "#"
send "exec /etc/init.d/rc.net reload\n"
expect "#"
send "exit"
exit

Am Anfang wird die telnet-Verbindung herausgelöst (gespawned) und gewartet bis die Box eine Zeile mit dem Inhalt password: zurückgibt. Danach wird mein Passwort hingeschickt, da meine Box abgesichert ist. Es ist immer empfehlenswert die Oberfläche des Routers abzusichern, das gleiche Passwort wird auch bei Telnet benutzt. Wichtig ist nur das jede Send-Zeile mit \n beendet werden muss, dies bestätigt den Befehl und darf nicht gelöscht werden wenn ihr euer Passwort ersetzt.
Im Anschluss folgen die Befehle, die ich vorher schon einmal beschrieben habe. Diese sehen leicht verändert aus, da man im Skript bestimmte Zeichen maskieren muss. Die zwei zusätzlichen Zeilen, die grep beinhalten verändern nichts an der Funktion und geben lediglich die Vorher- und Nachherwerte der beiden geänderten Parameter aus. Diese Ausgabe kann bspw. für ein Logfile verwendet werden.

Das Schlimmste ist geschafft, nun muss nur noch das Skript zum Ändern der MAC und das zum Neustarten des Modems zusammengführt werden. Ich habe das expect-Skript als fritz.sh im selben Ordner abgelegt und rufe dieses über ein anderes Skript namens reconnect.sh auf:

#!/bin/bash

DIR=$(cd $(dirname "$0"); pwd)
LOG=$DIR/reconnect.log
MACSCRIPT=$DIR/fritz.sh
PASSWORD=MySecretPasswordReplaceWithYourOwn

getIP() {
 curl http://ipecho.net/plain; echo
}


changeMAC() {
 $MACSCRIPT
}

restartModem() {
  curl http://192.168.100.1/goform/gscan -d SADownStartingFrequency=687000000
}

waitUntilOnline() {
while true
 do
  ping -c 1 ipecho.net >> $LOG
  if [[ $? == 0 ]]; then
   echo "Connection established. Waiting five more seconds." >> $LOG
   sleep 5
   break;
  else
   echo "Waiting..." >> $LOG
   sleep 5
  fi
 done
}


echo Old IP = $(getIP) > $LOG
echo Restarting Modem++++++++++++++++ >> $LOG
restartModem >> $LOG
echo Changing FritzBox Mac ++++++++++++++++ >> $LOG
changeMAC >> $LOG
waitUntilOnline
echo New IP = $(getIP) >> $LOG

Im Grunde ist das ganze ganz einfach. Zuerst wird die aktuelle IP ausgelesen und in eine Logdatei geschrieben. Anschließend wird das Modem neugestartet und die MAC der FritzBox geändert. waitUntilOnline prüft alle 5 Sekunden, ob die Internetverbindung schon wieder da ist um dann zum Schluss die neue IP ins Logfile zu schreiben.

Das war schon Alles ;) Das Skript kann man bestimmt noch etwas aufhübschen und etwas fehlertoleranter gestalten, es tut aber was es soll. Der Reconnect dauert zwischen 3 und 5 Minuten, da das Modem relativ träge ist bis es neu gestartet ist.

Falls ihr das Skript nachvollziehen wollt, muss ich vorher noch eine Warnung loswerden:
Die Skripte können im schlimmsten Fall die Box lahmlegen und es sollte vorher recherchiert werden, ob dies bei eurer FB genauso funktioniert. Ich kann und werde keine Garantie für kaputte Geräte übernehmen.

Ich konnte das Skript mit mehreren FritzBox-Modellen ausprobieren und es hat immer gut funktioniert. Im Zweifelsfall solltet ihr aber die einzelnen Teile der Telnet-Session einzeln ausprobieren, deshalb habe ich diese separat geschrieben. Ich konnte das Skript auch - mit leichten Anpassungen - unter Windows mit Hilfe von Cygwin laufen lassen. Folgendes musste ich dafür tun:

  • expect und curl nachinstallieren (waren in der Standardinstallation nicht vorhanden)
  • Der Ordner der Skripte durfte kein Leerzeichen beinhalten
  • Alle Logausgaben entfernt (> $LOG), habe nicht näher recherchiert warum das nicht funktioniert
  • Im expect-Skript die Zeile spawn telnet fritz.box durch spawn /usr/bin/telnet fritz.box ersetzt, da sonst das Win-Standard-Telnet benutzt wird.

Punkt 2 und 3 ist bestimmt auch anders lösbar, vielleicht will ja ein Windows-Nutzer seine Lösung posten.

Was ihr natürlich noch ändern müsst ist der Mechanismus zum Neustarten des Modems per URL, falls ihr ein anderes Modem habt. Dies sind aber im Netz relativ leicht zu finden.

Viel Spaß mit den beiden Skripten, ich freue mich auf eure Kommentare.

Samstag, 16. Juni 2012

Android: Admob-SDK (oder andere Bibliotheken) mit Maven nutzen

Wer Android-Entwicklung betreibt wird wissen das der komplette Build einer App standardmäßig auf Ant aufgebaut ist. Wer aber lieber (so wie ich) mit Maven arbeitet wird schnell auf das Problem stoßen, dass Bibliotheken nicht in den globalen Repositories zur Verfügung gestellt sind. Zum Beispiel das Admob SDK von Google steht nur als Jar zum Download bereit, welches ich hier als Beispiel nehme. Die Vorgehensweise funktioniert aber genauso mit jeder anderen Bibliothek. Prinzipiell hat man mehrere Möglichkeiten das mit Maven trotzdem hinzubekommen:

  1. Die Bibliothek auf ein eigenes Repository hochladen (ist für Firmen interessant die bspw. einen eigenen Artifactory- oder Nexus-Server zur Verfügung haben)
  2. Die Bibliothek ins Projekt mit aufnehmen und relativ mit dem Scope system und dem systemPath-Tag ins Projekt einbinden (ist imho ein Rückschritt was die Abhängigkeitenverwaltung in Maven angeht und muss außerdem für jedes Projekt wiederholt werden)
  3. Meine präferierte Möglichkeit ist die Installation in das lokale Repository auf die ich nun näher eingehen will. 
Zuallererst laden wir uns das Admob-SDK (zur Zeit ist Version 6.0.1 aktuell) und legen es in ein beliebiges Verzwichnis. In diesem Verzeichnis legen wir zusätzlich eine Datei mit dem Namen pom.xml an und füllen Sie mit folgendem Inhalt:


    4.0.0
    com.blogspot.problemexterminator
    install-admob
    1.0.0
    
    
        install:install-file
        
            
                org.apache.maven.plugins
                maven-install-plugin
                2.3.1
                
                    GoogleAdMobAdsSdk-6.0.1.jar
                    com.google.ads
                    admob
                    jar
                    6.0.1
                
            
        
    

Es wird in dieser Pom einfach nur das install-Plugin für die Installation in das lokale Repository konfiguriert. Wichtig ist, dass folgende Tags (innerhalb <configuration> richtig definiert sind:

  • <file> Dateipfad der heruntergeladenen Jar (relativ zur Pom)
  • <groupId> - frei wählbar, über diesen wird später in den anderen Poms das SDk referenziert
  • <artifactId>  - frei wählbar, über diesen wird später in den anderen Poms das SDk referenziert
  • <version> - ebenfalls frei wählbar, jedoch sollte dies mit der Version des SDK übereinstimmen
Jetzt muss einfach nur mit der Kommandozeile zum richtigen Ordner navigiert werden und "mvn" ausgeführt werden:



Da das Default-Goal in der Pom bereits auf install-file gesetzt ist, muss hier nichts weiter hinzugefügt werden und Admob ist in eurem lokalen Repository.

 Nun kann in jedem beliebigen Projekt und in jedem beliebigen Scope Admob ganz normal referenziert und verwendet werden:


....
   
        
        ....
            
                com.google.ads
                admob
                6.0.1
            
        
    
Wie bereits erwähnt ist wichtig, dass beim Referenzieren die artifactId, groupId und die Versionsnummer aus der vorherigen Pom übereinstimmt.

Das Beispiel für die Installation von Admob ins lokale Repository steht hier zum Download bereit, lediglich mvn muss noch selbst ausgeführt werden.

Viel Spaß damit. ;)


Montag, 11. Juni 2012

RamDisk Auf 64-Bit Windows und Temp-Verzeichnisse ändern

Eine RamDisk ist ein virtuelles Laufwerk in eurem Rechner das einzig und allein im Arbeitsspeicher abgelegt ist. Der Vorteil liegt darin, dass der Zugriff darauf extrem schnell ist (5-10mal schneller als bspw. der Zugriff auf eine SSD). Davon kann man bspw. profitieren, wenn man sein temporäres Verzeichnis darauf ablegt, weil viele Programme dies nutzen, um Dateien kurzzeitig zwischenzuspeichern. Die meisten Setups "parken" hier ihre Dateien zwischen, ebenso wie die meisten Packtools (7-zip, WinRAR). Ein weiterer Vorteil ist, dass dieses Laufwerk nach einem Neustart des Rechners immer automatisch geleert wird also kein Datenmüll übrig bleibt. Das kann man auch dafür nutzen, um die Cache-Verzeichnisse des Browsers darauf abzulegen (z.B. für Chrome) was wiederum auch Vorteile in Bezug auf Datensicherheit bringt.

Eine RamDisk unter Windows einzurichten ist vom Prinzip her keine große Sache und es gibt auch einige kostenlose Programme dafür. Die meisten unterliegen aber Beschränkungen wie bspw. nur lauffähig auf 32-Bit Betriebssystemen, Werbung oder Beschränkung auf 4 GB. Gerade wer ein 64-Bit Windows installiert hat und viel Arbeitsspeicher zur Verfügung hat kann von einer großen RamDisk profitieren. Das beste Programm für diesen Zweck ist meiner Meinung nach ImDisk. Keine Werbung, keine Größenbeschränkung, auf 64-Bit lauffähig und skriptfähig. Außerdem ist für das Anlegen/Ändern kein Neustart notwendig. ImDisk hat außer der RamDisk-Funktion noch einiges mehrt zu bieten auf das ich aber hier nicht näher eingehen will.

Die folgende Anleitung funktioniert genau so auch unter 32-Bit Betriebssystemen, jedoch kann leider nicht so viel Speicher verwendet werden.

Ladet euch den Installer herunter ("Download ImDisk install package") und installiert das Programm. Nun findet man in der Systemsteuerung einen neuen Eintrag für ImDisk, welches die grafische Oberfläche zur Verfügung stellt:

Für einen Anfänger und zum Ausprobieren ist dies ganz gut, hat jedoch den Nachteil das nach einem Neustart das virtuelle Laufwerk weg ist und das neu angelegte virtuelle Laufwerke formatiert werden muss. Aus diesem Grund beziehe ich mich hier auf die Kommandozeile von ImDisk, die automatisch dabei ist.

Zuerst starten wir eine Konsole mit Adminstratorrechten und legen ein Laufwerk R mit bspw. 5 Gigabyte an. Die Größe und der Laufwerksbuchstabe kann natürlich frei gewählt werden:

imdisk -a -s 5G -m R: -p "/fs:ntfs /q /y"

Zur Erklärung:

  • -a legt ein neues virtuelles Laufwerk an
  • -s 5G legt die Größe auf 5Gigabyte fest
  • -m R: weist den Laufwerksbuchstaben R: (für RamDisk) zu
  • -p "/fs:ntfs /q /y" übergibt die Parameter an den Windows-Format-Befehl (als NTFS formatieren, schnelles Formatieren und ohne Rückfrage)
Wenn das geklappt hat, ist nun im Explorer ein neues Laufwerk mit 5 Gigabyte Speichergröße vorhanden und kann genutzt werden. Nachdem wir nun den richtigen Befehl gefunden haben müssen wir ImDisk nur noch dazu bringen dies immer automatisch nach einem Neustart einzubinden. Im Autostart-Ordner funktioniert leider nicht, da für das automatisch Formatieren Adminrechte benötigt werden. Als Ersatz kann hierfür die Aufgabenplanung genutzt werden.
In der Aufgabenplanung erstellen wir eine neue Aufgabe (nicht die einfache Aufgabe erstellen, da diese zu wenig Optionen hat) und füllen die erforderlichen Felder aus:



Der Name ist frei wählbar, wichtig ist aber das "mit höchsten Privilegien" ausgewählt ist.
Beim Reiter Trigger erstellen wir einen neuen Trigger so das die Aufgabe bei jedem Systemstart ausgeführt wird:


Nun folgt der Reiter Aktion, wo wir nun das eigentliche Anlegen der RamDisk durchführen:


Der Pfad zur imdisk.exe ist normalerweise C:\Windows\System32\imdisk.exe und wird hier ausgewählt. Wichtig sind zudem die Argumente, die wir vorher in der Kommandozeile bestimmt haben. (im Bsp. ist das -a -s 5G -m R: -p "/fs:ntfs /q /y" )

Nun legen wir noch die temporären Ordner auf diese RamDisk um von der eben angelegten RamDisk zu profitieren. Wichtig ist vorher einen Neustart durchzuführen, um zu überprüfen, ob das automatische Anlegen der RamDisk funktioniert hat.

Um alle Temp-Verzeichnisse auf die RamDisk zu legen müssen wir nur ein paar Umgebungsvariablen anpassen. Dazu starten wir die Systemeigenschaften (Win+Pause) und klicken auf "Erweiterte Systemeinstellungen". Beim Reiter "Erweitert sehen wir nun ganz unten den Knopf "Umgebungsvariablen":


Bei den Umgebungsvariablen ändern wir nun die Benutzervariablen TEMP und TMP und auch die Systemvaraiblen TEMP und TMP auf das neue Laufwerk ab (hier: R:\). Im Anschluss sollte das dann folgendermaßen aussehen:


Ein letzter Neustart, um zu überprüfen, ob Alles funktioniert und schon sind wir fertig.

Samstag, 31. März 2012

Google Chrome (Standardbrowser) Cache-Verzeichnis ändern

Wer bei Google Chrome das Cache-Verzeichnis ändern will muss nur den Parameter:

--disk-cache-dir=<Verzeichnis> 

an die Verknüpfung anhängen.



Dies ist z.B. hilfreich, wenn man eine Ramdisk eingerichtet hat, um den Browser zusätzlich zu beschleunigen. Ein weiterer Vorteil ist, dass nach einem Neustart der Cache wieder komplett leer ist. Das funktioniert auch ganz gut, ein Problem gibt es jedoch. Man muss diese Einstellung für jede Verknüpfung machen (Desktop, Schnellstartleiste, Startmenü). Meist startet man den Standard-Browser außerdem über irgendeinen Link oder auch über die Standardprogramme im Startmenü (Browser und E-Mail). Hier werden natürlich die Einstellungen in den Browser-Verknüpfungen ignoriert. Doch auch hierfür gibt es Abhilfe durch einen kleinen Eintrag in der Registry. Der zu ändernde Schlüssel ist zu finden unter:

HKEY_CLASSES_ROOT\ChromeHTML\shell\open\command


Hier findet man den auf der rechten Seite einen Schlüssel, der den Standardpfad zur chrome.exe enthält.


Eine Anpassung hier wirkt sich dann global aus. Einfach den gewünschten Parameter zwischen den Pfad und die %1 schreiben und fertig.



Meine komplette Zeile sieht so aus:

"C:\Users\problemexterminator\AppData\Local\Google\Chrome\Application\chrome.exe" --disk-cache-dir=f:\cache -- "%1"


Bei euch wird natürlich der Pfad zur chrome.exe aufgrund des Benutzernamens abweichen. Für den der es etwas einfacher will habe ich den betroffenen Schlüssel exportiert:

Windows Registry Editor Version 5.00

[HKEY_CLASSES_ROOT\ChromeHTML\shell\open\command]
@="\"C:\\Users\\problemexterminator\\AppData\\Local\\Google\\Chrome\\Application\\chrome.exe\" --disk-cache-dir=f:\\cache -- \"%1\""


Einfach den Inhalt in einer Textdatei abspeichern und ihr die Endung *.reg geben (z.B. chrome.reg). Passt dann den Benutzernamen und das Cache-Verzeichnis auf eure Bedürfnisse an. Nun noch doppelt auf die Datei geklickt, die Sicherheitsfrage bestätigt und das Cache-Verzeichnis des Chrome ist nun immer auf der RamDisk.

Viel Spaß beim Ausprobieren.



Freitag, 30. März 2012

Einen bestimmten Java-Prozess per Batch beenden

Wenn man einen Prozess per Batch-Datei beenden will, funktioniert das unter Windows ganz einfach mit dem Befehl taskkill. Dies funktioniert jedoch nicht, wenn man einen bestimmten Java-Prozess beenden will. Natürlich kann man die java.exe abschießen, was aber dazu führt, dass man alle Java-Prozesse beendet. Wer bspw. - so wie ich - den JBoss-Applikationsserver per Skript beenden will und gleichzeitig eine Java-IDE laufen hat beendet mit taskkill /f /im java.exe beide Anwendungen. Abhilfe schafft hierbei das Kommandozeilentool jps aus dem Oracle JDK. Mit dem Parameter -v sieht man alle laufenden Anwendungen mit den zugehörigen Kommandozeilenparametern. Standardmäßig ist das JDK unter c:\Program Files\Java\jdk<Versionsnummer>\ installiert, das Programm befindet sich im bin-Ordner.
Für ein Beispiel laufen hier einmal 3 Java-Programme (inkl. JBoss) gleichzeitig:


Wie man erkennen kann, gibt jps auch die Prozess-ID aus, was uns helfen wird den Prozess zu beenden. Wenn man den Prozess, den man beenden will herausgefunden hat, sucht man sich ein Teil aus der Kommandozeile aus, der ziemlich eindeutig ist. Ich nehme für den JBoss z.B. run.bat. Hiermit habe ich nun die Möglichkeit mit einer Pipe und einer Suche die Prozess-ID zu finden, um den JBoss zu beenden. Meine Batch sieht folgendermaßen aus:

@echo off
set jps_path=c:\Program Files\Java\jdk1.7.0_03\bin\
set command=jps -v
cd /d "%jps_path%"
FOR /f "tokens=1" %%G IN ('%command% ^| find "run.bat"') DO taskkill /f /pid %%G

Einfach den Schnipsel unter kill_JBoss.bat speichern, starten und nur der JBoss wird beendet. Der Pfad zum Bin-Ordner des JDK muss eventuell noch angepasst werden. Der Suchbegriff (hier: run.bat" steht in der for-Schleife und kann auf euren Prozess angepasst werden.
Im Ergebnis sieht das ganze dann so aus (Ich gebe vorher noch einmal alle Java-Prozesse aus):

Samstag, 10. März 2012

JDownloader auf Linux-Server ohne X11-Frontend betreiben

Wer einen eigenen Root-Server mit Linux betreibt, stellt sich vielleicht die Frage, ob es möglich ist den JDownloader auch ohne grafisches Frontend zu installieren und nur das Webinterface zu nutzen. Eine Installation funktioniert ohne Probleme, aber der JD startet leider nur mit Exceptions, da die GUI nicht geladen werden kann. Ein grafisches Frontend kann man natürlich auf einem Server nicht ohne Weiters starten und das X11-Interface ist auch schwierig zu holen, wenn man von Windows aus administriert.Dem kann man aber Abhilfe schaffen, indem man mit dem virtuellen Framebuffer herumspielt. Wie und ob das funktioniert erfahrt ihr hier.

Als Grundlage dient ein Debian Squeeze ohne X11. Für die Installation benötigen wir einige Tool, die benötigt werden:

  • Java (für den JDownloader)
  • xvfb (der virtuelle Framebuffer)
  • x11vnc (für die Administration)
  • den JDownloader
Zunächst installieren wir erst einmal als superuser Java, xvfb und x11vnc:

apt-get install x11vnc openjdk-6-jre xvfb

Ich verwende das OpenJDK anstelle des offiziellen Oracle-Paketes. Dafür muss nichts extra getan werden, da dies in den Paketquellen enthalten ist. Nach erfolgreicher Installation laden wir den JDownloader und installieren ihn (die URL kann sich unterscheiden, bitte auf der Downloadseite überprüfen):

wget http://installer.jdownloader.org/jd_unix_0_9.sh
chmod +x jd_unix_0_9.sh
./jd_unix_0_9.sh

Nach einigen Fragen des Installers ist der JDownloader nun im Verzeichnis /usr/local/jdownloader installiert. Für das einmalige Einrichten des Webinterfaces und des Downloadordners, etc. müssen wir den JD starten. Dafür benötigen wir das grafische Frontend, welches wir in den virtuellen Framebuffer umleiten. Danach ist dieser per VNC konfigurierbar. Wichtig ist, dass alle Befehle als Hintergrundjob gestartete werden, das hat den Vorteil, dass nur eine SSH_Session benötigt wird:

Xvfb -screen 0 800x600x16 -ac & 
DISPLAY=:0 java -jar /usr/local/jdownloader/JDownloader.jar &
x11vnc -display :0 &

Durch die eingegebenen Befehle haben wir ein virtuelles Display 0 mit der Größe 800x600 Pixel, Farbtiefe 16-Bit angelegt. Auf diesem haben wir den JDownloader gestartet. Der letzte Befehl startet den VNC-Server der das eben angelegte Display weiterleitet. Nun sollte eine Verbindung per VNC (z.B.: TightVNC) möglich sein:


Alle gewünschten Einstellungen können nun ausgeführt werden. Mindestens sollte aber das Webinterface installiert sein und/oder alle AGBs bestätigt werden.

In der Konsole kann nun der JDownloader neu gestartet werden und das Webinterface ausprobiert werden:

pkill -f java
DISPLAY=:0 java -jar /usr/local/jdownloader/JDownloader.jar &
Wenn dies klappt sind wir schon fast fertig. Die Fenstergröße des virtuellen Displays wird natürlich nicht so groß gebraucht und der VNC-Server wird nicht mehr gebraucht. Deshalb beenden wir erst einmal alles:


pkill -f java
pkill -f x11vnc
pkill -f Xvfb


Als letzten Schritt wird das virtuelle Display mit einer Größe von 1x1 Pixeln und 8 Bit Farbtiefe gestartet. Nun noch den JDownloader wieder starten und das Webinterface sollte erreichbar sein:


Xvfb -screen 0 1x1x8 -ac & 
DISPLAY=:0 java -jar /usr/local/jdownloader/JDownloader.jar &


Wenn alles richtig durchgeführt wurden ist, sieht das ungefähr so aus (Hinweis: der verlängerte Befehl zum Start des JD dient nur der Unterdrückung der Ausgabe für den Screenshot) :




Android Werbung ohne Root entfernen

Vorneweg noch ein paar Worte: Viele Webseiten oder Apps im Android Market schalten Werbung, um damit ihre Kosten für die Betreibung der Server oder die Entwicklung zu sichern. Deshalb ist das Deaktivieren der Werbung ein zweischneidiges Schwert. Bei Apps oder Webseiten, die euch gefallen solltet ihr ruhig den Werbeblocker deaktivieren und/oder auf Werbung klicken, um kostenlose Angebote zu fordern.

Bei Smartphones und den damit verbundenen Tarifen ist es durchaus nützlich Werbung zu blockieren, um die -sowieso schon begrenzte -  Bandbreite zu schonen. Im Market gibt es zum Blocken von Werbung schon eine App namens Adfree. Leider hat diese einen Nachteil und zwar das Root-Rechte benötigt werden. Wenn man jedoch sein Smartphone nicht rooten möchte, muss man mit der Werbung leben.

Hinweis: Die Anleitung richtet sich an versierte Nutzer. Es ist durchaus möglich, damit auch Schaden am Gerät oder an der Firmware anzurichten. Ich übernehme keine Haftung für eventuelle Schäden.

Die App Adfree basiert darauf, dass eine Liste von bekannten Werbeservern in die Hosts-Datei des Betriebssystems eingetragen werden und diese mit der lokalen IP (127.0.0.1) verbunden wird. Deshalb wird jede Anfrage an einen dort eingetragenen Server auf das eigene Gerät umgeleitet. Beispiele für solche Hosts-Dateien gibt es im Netz zu finden. Diese werden später für die Anleitung benötigt. Ladet euch eine Datei herunter und speichert diese unter hosts.txt. Downloads gibt es z.B. hier:




Mit ein paar Linux-Kenntnissen ist es möglich dieses Verhalten manuell zu tun, um damit die Werbung zu blocken. Dazu benötigt man das Android SDK, in dem z.B. das Tool adb enthalten ist. Dieses wird benötigt, um eine Shell auf dem Telefon zu starten. Einfach den Installer laden und die Tools in einen Ordner eurer Wahl installieren. Den SDK Manager im Anschluss starten und die Plattform-Tools installieren. Alles andere kann abgewählt werden:


Im Telefon muss Debugging noch aktiviert werden, damit wir Verbindung aufnehmen können. Das ist zu finden unter Einstellungen -> Anwendungen - >Entwicklung:



Im Folgenden wird davon ausgegangen, dass das SDK in D:\android-sdk-windows installiert ist und das Telefon an den USB-Anschluss angeschlossen ist (Nur Laden). Die vorher heruntergeladene Hosts-Datei ist im Unterordner platform-tools abgelegt. Also unter d:\android-sdk-windows\platform-tools\hosts.txt.
Zuerst starten wir eine Konsole (Win+R->cmd->Enter), hangeln uns zu den Plattform-Tools durch und starten eine Shell per ADB:

cd /d "d:\android-sdk-windows\platform-tools"
adb shell

Auch wenn keine weitere Ausgabe erfolgts sind wir nun auf dem Gerät eingeloggt. Zuerst müssen wir die Systempartition schreibbar machen, standardmäßig ist diese nur lesbar. Im Anschluss beenden wir die Shell gleich wieder:

mount -o remount,rw /system
exit

Die Hosts-Datei muss nun auf das Gerät übertragen werden. Dafür benutzen wir den push-Befehl und speichern diese gleich auf dem Gerät unter /system/etc (der Ordner kann sich bei anderen Geräten unterscheiden, dies ist aber der Standardpfad!) ab. Nun gehen wir zurück aufs Gerät und browsen direkt zum Ordner

adb push hosts.txt /system/etc
adb shell
cd /system/etc

Aus Sicherheitsgründen benennen wir die alte Hosts-Datei um und geben der neuen Datei ihren Namen:

mv hosts hosts_old
mv hosts.txt hosts

Nun noch die Shell beenden und das Gerät neu starten. Nun sollte die Werbung komplett entfernt sein.
Hier noch einmal ein Screenshot der kompletten Vorgehensweise: