rm -fr /rpool/opensolaris
install gentoo linux
emerge -avt zfs-fuse
Ich haette es gleich von Anfang an so machen sollen...
Mittwoch, 25. August 2010
Aus aktuellem Anlass
Ich haette es gleich von Anfang an so machen sollen...
Samstag, 14. November 2009
Whiskey-Verbot für Jugendliche?
Hinweis:
Diesen Post bitte nur lesen, wenn du schon volljährig bist ;-)
Diesen Post bitte nur lesen, wenn du schon volljährig bist ;-)
Heute spielte ich auf meiner Playstation 3 das Spiel "Band Hero" und bei dem Song "American Pie" von Don McLean dachte ich, jetzt muß ich scheinbar echt mal dringend zum Ohrenarzt gehen.
An der Songstelle "good old boys were drinking whiskey and rye" hörte ich immer nur "good old boys were drinking w and rye".
Zuerst dachte ich an einen Bug im Spiel, dann hatte ich die Theorie, dass der alte Don McLean bei der Aufnahme eventuell ein bisserl zu viel vom Whiskey intus hatte und ihn dann einfach nicht mehr singen konnte.
Schlußendlich blickte ich dann auf das Cover des Spiels und dort stand: "USK ab 0 freigegeben".
Und da schoss es mir durch den Kopf und ich begab mich gleich einmal auf Recherche im Internet und tatsächlich findet man dort öfters den Hinweis, daß das Wort Whiskey rausgeschnitten wurde, damit man in den USA das "ESRB 10+"-Rating bekommt und das Spiel auch an Teenager verkaufen darf. Teenager dürften bei der Band Hero Songlist wohl die primäre Zielgruppe sein.
Na bravo, Jugendliche dürfen also Whiskey nicht trinken und zusätzlich nicht aussprechen und auch nicht hören.
Ich hoffe nur, dass ich mich heute nicht strafbar gemacht habe, da ich das Wort Whiskey ca. 5 mal in der Gegenwart meiner 3-jährigen Tochter gesagt habe.
Interessant ist in dem Zusammenhang aber, daß man über "Rye" singen darf und über "Whiskey" nicht.
Weiters dürften jedoch folgende Zeilen des Songs "Gasoline" der Zensur durch die Finger gerutscht sein: "... we were only seventeen ... at your mother's house and your father would find my hand inside your blouse ...". Was damit wohl gemeint ist ;-)
Donnerstag, 22. Oktober 2009
Android Binaries decompilieren?
Als Software-Entwickler habe ich mir die Frage gestellt, ob es denn eigentlich möglich ist, meine Android Anwendungen wieder zu decompilieren bzw. zu disassemblieren.
Bekannterweise verwendet die Dalvik Virtual Machine der Android Plattform ja ein eigenes Format (Dalvik Executeables) für die compilierten Java-Klassen und nicht das Standard Java .jar-Format mit den entsprechenden .class-Dateien. Somit ist ein Decompilen mit Tools wie "Jad" oder ähnlichem nicht möglich.
Diese Dalvik Executeables (.dex) Dateien befinden sich bei einer installierten Anwendung in der Android Package Datei (ist ein normales Zip-File mit der Dateiendung .apk) und heißen "classes.dex". Erstellt werden sie mit dem "dx" Tool aus den Java .class-Dateien, welches im Android SDK enthalten ist.
Auf der Suche nach einem Decompiler/Disassembler bin ich sehr schnell auf zwei Open Source Projekte gestoßen, die beide ganz einfach zu handhaben sind:
Dedexer - a disassembler tool for DEX file
http://dedexer.sourceforge.net
smali - An assembler/disassembler for Android's dex format
http://code.google.com/p/smali/
Nachfolgend eine kleine Demonstration, wie ich eine sehr einfache Demo Applikation mit Dedexer disassembliert habe:
1) Zuerst habe ich mit dem Android SDK unter Eclipse ein neues Android Projekt angelegt (TestApp) und folgenden simplen Code in die generierte Activity Klasse geschrieben:
2) Danach habe ich testweise die Applikation einmal im Emulator gestartet und mir im LogCat den Output angeschaut:
Perfekt, funktioniert - was soll bei den paar Zeilen Code auch schon falsch sein ;-)
3) Im bin-Verzeichnis des Android Projektes findet sich nun die Datei "TestApp.apk", welche die ganze Anwendung enthält. Der Aufruf von "unzip TestApp.apk" liefert folgendes:
4) Der Java-Code ist wie schon erwähnt in der Datei classes.dex, die als nächstes mit dem Dedexer zu zerlegen ist. Für die Installation von Dedexer ist nur die Datei "ddx1.7.jar" von SourceForge notwendig und danach kann man mit folgendem Befehl die classes.dex disassemblieren:
Als Output bekommt man folgendes:
Für jede ursprüngliche .class-Datei der Anwendung erhält man so wieder eine Datei, welche den disassemblieren Code in einem Assembler-ähnlichen Format enthält. Diese Dateien haben als Dateieindung ".ddx".
Die Datei "TestApp.ddx" sieht nun wie folgt aus:
Wenn man ein wenig Assembler-Erfahrung hat findet man sich in dem disassemblieren Code recht schnell zu Recht. Die verschiedenen Opcodes der Dalvik VM sind auf http://pallergabor.uw.hu/androidblog/dalvik_opcodes.html beschrieben.
Bekannterweise verwendet die Dalvik Virtual Machine der Android Plattform ja ein eigenes Format (Dalvik Executeables) für die compilierten Java-Klassen und nicht das Standard Java .jar-Format mit den entsprechenden .class-Dateien. Somit ist ein Decompilen mit Tools wie "Jad" oder ähnlichem nicht möglich.
Diese Dalvik Executeables (.dex) Dateien befinden sich bei einer installierten Anwendung in der Android Package Datei (ist ein normales Zip-File mit der Dateiendung .apk) und heißen "classes.dex". Erstellt werden sie mit dem "dx" Tool aus den Java .class-Dateien, welches im Android SDK enthalten ist.
Auf der Suche nach einem Decompiler/Disassembler bin ich sehr schnell auf zwei Open Source Projekte gestoßen, die beide ganz einfach zu handhaben sind:
Dedexer - a disassembler tool for DEX file
http://dedexer.sourceforge.net
smali - An assembler/disassembler for Android's dex format
http://code.google.com/p/smali/
Nachfolgend eine kleine Demonstration, wie ich eine sehr einfache Demo Applikation mit Dedexer disassembliert habe:
1) Zuerst habe ich mit dem Android SDK unter Eclipse ein neues Android Projekt angelegt (TestApp) und folgenden simplen Code in die generierte Activity Klasse geschrieben:
package com.blackcap.android;
import android.app.Activity;
import android.os.Bundle;
import android.util.Log;
public class TestApp extends Activity {
private final static String LOG_TAG = "TestApp";
/** Called when the activity is first created. */
@Override
public void onCreate(Bundle savedInstanceState) {
String text = "Hallo Android";
int quersumme = 0;
for (int i = 0; i < text.length(); i++) {
char c = text.charAt(i);
quersumme += (c);
}
Log.i(LOG_TAG, "quersumme = " + quersumme);
if (quersumme == 1233) {
Log.i(LOG_TAG, "Quersumme ist korrekt!");
} else {
Log.i(LOG_TAG, "Quersumme fehlerhaft!");
}
super.onCreate(savedInstanceState);
setContentView(R.layout.main);
}
}
2) Danach habe ich testweise die Applikation einmal im Emulator gestartet und mir im LogCat den Output angeschaut:
10-22 19:04:04.375: INFO/TestApp(862): quersumme = 1233
10-22 19:04:04.375: INFO/TestApp(862): Quersumme ist korrekt!
Perfekt, funktioniert - was soll bei den paar Zeilen Code auch schon falsch sein ;-)
3) Im bin-Verzeichnis des Android Projektes findet sich nun die Datei "TestApp.apk", welche die ganze Anwendung enthält. Der Aufruf von "unzip TestApp.apk" liefert folgendes:
Archive: /home/hschwarz/workspace/TestApp/bin/TestApp.apk
extracting: res/drawable/icon.png
inflating: res/layout/main.xml
inflating: AndroidManifest.xml
extracting: resources.arsc
inflating: classes.dex
inflating: META-INF/MANIFEST.MF
inflating: META-INF/CERT.SF
inflating: META-INF/CERT.RSA
4) Der Java-Code ist wie schon erwähnt in der Datei classes.dex, die als nächstes mit dem Dedexer zu zerlegen ist. Für die Installation von Dedexer ist nur die Datei "ddx1.7.jar" von SourceForge notwendig und danach kann man mit folgendem Befehl die classes.dex disassemblieren:
java -jar ddx1.7.jar -d . classes.dex
Als Output bekommt man folgendes:
Processing com/blackcap/android/R$attr
Processing com/blackcap/android/R$drawable
Processing com/blackcap/android/R$layout
Processing com/blackcap/android/R$string
Processing com/blackcap/android/R
Processing com/blackcap/android/TestApp
Für jede ursprüngliche .class-Datei der Anwendung erhält man so wieder eine Datei, welche den disassemblieren Code in einem Assembler-ähnlichen Format enthält. Diese Dateien haben als Dateieindung ".ddx".
Die Datei "TestApp.ddx" sieht nun wie folgt aus:
.class public com/blackcap/android/TestApp
.super android/app/Activity
.source TestApp.java
.field private static final LOG_TAG Ljava/lang/String; = "TestApp"
.method public()V
.limit registers 1
; this: v0 (Lcom/blackcap/android/TestApp;)
.line 7
invoke-direct {v0},android/app/Activity/; ()V
return-void
.end method
.method public onCreate(Landroid/os/Bundle;)V
.limit registers 9
; this: v7 (Lcom/blackcap/android/TestApp;)
; parameter[0] : v8 (Landroid/os/Bundle;)
.var 0 is c C from l4bc to l4c4
const-string v6,"TestApp"
.line 13
const-string v3,"Hallo Android"
.line 15
const/4 v2,0
.line 16
const/4 v1,0
l458:
invoke-virtual {v3},java/lang/String/length ; length()I
move-result v4
if-lt v1,v4,l4b4
.line 21
const-string v4,"TestApp"
new-instance v4,java/lang/StringBuilder
const-string v5,"quersumme = "
invoke-direct {v4,v5},java/lang/StringBuilder/; (Ljava/lang/String;)V
invoke-virtual {v4,v2},java/lang/StringBuilder/append ; append(I)Ljava/lang/StringBuilder;
move-result-object v4
invoke-virtual {v4},java/lang/StringBuilder/toString ; toString()Ljava/lang/String;
move-result-object v4
invoke-static {v6,v4},android/util/Log/i ; i(Ljava/lang/String;Ljava/lang/String;)I
.line 23
const/16 v4,1233
if-ne v2,v4,l4c4
.line 24
const-string v4,"TestApp"
const-string v4,"Quersumme ist korrekt!"
invoke-static {v6,v4},android/util/Log/i ; i(Ljava/lang/String;Ljava/lang/String;)I
l4a2:
.line 29
invoke-super {v7,v8},android/app/Activity/onCreate ; onCreate(Landroid/os/Bundle;)V
.line 30
const/high16 v4,32515
invoke-virtual {v7,v4},com/blackcap/android/TestApp/setContentView ; setContentView(I)V
.line 31
return-void
l4b4:
.line 17
invoke-virtual {v3,v1},java/lang/String/charAt ; charAt(I)C
move-result v0
l4bc:
.line 18
add-int/2addr v2,v0
.line 16
add-int/lit8 v1,v1,1
goto l458
l4c4:
.line 26
const-string v4,"TestApp"
const-string v4,"Quersumme fehlerhaft!"
invoke-static {v6,v4},android/util/Log/i ; i(Ljava/lang/String;Ljava/lang/String;)I
goto l4a2
.end method
Wenn man ein wenig Assembler-Erfahrung hat findet man sich in dem disassemblieren Code recht schnell zu Recht. Die verschiedenen Opcodes der Dalvik VM sind auf http://pallergabor.uw.hu/androidblog/dalvik_opcodes.html beschrieben.
Samstag, 17. Oktober 2009
Fehlerhafte USB Platte (ASC=0x0 ASCQ=0x0 Sense Key : 0x0)
Meine externe USB-Platte (Western Digital MyPasswort 320 GB) hat seit kurzem einen Hardware-Defekt und an bestimmten Stellen blieb der Zugriff unter Linux (Kernel 2.6.30) in einer Endlosschleife hängen.
Im /var/log/messages standen dann folgenden Zeilen, die sich laufend wiederholten:
USB: storage: When a device returns no sense data, call it a Hardware Error
http://patchwork.kernel.org/patch/54331/
Den Patch habe ich dann bei meinem 2.6.30'er Kernel angewendet und jetzt bekomme ich endlich sinnvolle Error-Meldungen:
Im /var/log/messages standen dann folgenden Zeilen, die sich laufend wiederholten:
sd 10:0:0:0: [sdb] ASC=0x0 ASCQ=0x0Meine Google-Recherchen brachten mich dann zu folgendem ganz neuen Patch für den 2.6.31'er Kernel vom 16.Oktober 2009:
sd 10:0:0:0: [sdb] Sense Key : 0x0 [current]
Info fld=0x0
USB: storage: When a device returns no sense data, call it a Hardware Error
http://patchwork.kernel.org/patch/54331/
Den Patch habe ich dann bei meinem 2.6.30'er Kernel angewendet und jetzt bekomme ich endlich sinnvolle Error-Meldungen:
sd 10:0:0:0: [sdb] Unhandled sense codePerfekt, jetzt kann ich endlich die Platte komplett löschen und dann umtauschen.
sd 10:0:0:0: [sdb] Result: hostbyte=0x07 driverbyte=0x08
sd 10:0:0:0: [sdb] Sense Key : 0x4 [current]
Info fld=0x0
sd 10:0:0:0: [sdb] ASC=0x0 ASCQ=0x0
end_request: I/O error, dev sdb, sector 558218191
Sonntag, 27. September 2009
NXServer (FreeNX) unter OpenSolaris 2009.06 (x86)
Um auf meinem Server ein paar Dinge grafisch zu administrieren habe ich mir FreeNX (Remote Desktop Variante für Unix) installiert.
Die Binaries für OpenSolaris gibt es auf http://www.opensolaris.org/os/project/awards/awards_land/Entries/. Dazu muss man einfach die Datei http://dlc.sun.com/osol/awards/downloads/current/freenx.tar.gz runterladen und in einem temporären Verzeichnis entpacken. Dann das Verzeichnis freenx/freenx-0.7.2-nx-3.1-nevada-b90-x86/opt/NX nach /opt verschieben und mit "chown -R root:bin /opt/NX" den Besitzer richtig setzen.
Laut README sollte nun ein "/opt/NX/bin/nxsetup --install" genügen, um die Installation abzuschliessen. Da kamen bei mir aber gleich mal ein paar Fehlermeldungen, da die Binaries offenbar nicht mehr so hundertprozentig zum aktuellen OpenSolaris passen. Und beim Aufbau einer Verbindung lief ich auch dauernd in ein Timeout.
Um diese Fehler zu beheben ist folgendes notwendig:
1) Fehlende Pakete mit SUNWcups, SUNWexpect, SUNWnetcat aus dem OpenSolaris Repository nachinstallieren.
2) Die Meldung "sed: command garbled: s/%BACKEND%/3.1.0" kann man durch folgende Änderung beseitigen. Das Problem ist nämlich, dass in einem Script das strings Kommando zwei Zeilen zurückliefert und nicht eine Zeile. Einfach die Datei /opt/NX/bin/nxloadconfig öffnen (zuvor eine Sicherungskopie machen) und folgende Zeile ( bei mir in Zeile 312) wie folgt ändern:
ersetzen durch:
3) Und zuletzt ist in der Datei /opt/NX/bin/nxnode (zuvor wieder eine Sicherungskopie anlegen) folgende Zeile (direkt nach Zeile 1013 "uniqueid=$(getparam uniqueid)") einzufügen. Das ganze ist ein Workaround für die komischen Unicode-Zeichen anstelle der Buchstaben BCDEF in den Session-Id's. Ich habe nicht näher erforscht, warum die da sind, aber so werden sie korrekt verwendet:
Und dann hat's bei mir funktioniert. Ohne diese Änderungen ist der Client beim Verbinden immer hängengeblieben und wenn man im Internet recherchiert sieht man, dass einige Leute auch diese Probleme haben.
Was kann man nun machen, wenn man auch weiterhin keine Verbindung zustande bringt. In der Datei /opt/NX/bin/nxloadconfig kann man durch folgende Änderung das Debugging in die Datei /var/log/nxserver.log aktivieren:
ist zu ersetzen durch:
Und dann kann man sich einfach an Hand der Fehlermeldungen durch die einzelnen Scripts hanteln und nach möglichen Fehlern suchen.
Ein Blick in das Blog des Paket-Maintainers (und die Kommentare) auf http://www.kraftek.com/blog/ kann eventuell auch weiterhelfen.
Die Binaries für OpenSolaris gibt es auf http://www.opensolaris.org/os/project/awards/awards_land/Entries/. Dazu muss man einfach die Datei http://dlc.sun.com/osol/awards/downloads/current/freenx.tar.gz runterladen und in einem temporären Verzeichnis entpacken. Dann das Verzeichnis freenx/freenx-0.7.2-nx-3.1-nevada-b90-x86/opt/NX nach /opt verschieben und mit "chown -R root:bin /opt/NX" den Besitzer richtig setzen.
Laut README sollte nun ein "/opt/NX/bin/nxsetup --install" genügen, um die Installation abzuschliessen. Da kamen bei mir aber gleich mal ein paar Fehlermeldungen, da die Binaries offenbar nicht mehr so hundertprozentig zum aktuellen OpenSolaris passen. Und beim Aufbau einer Verbindung lief ich auch dauernd in ein Timeout.
Um diese Fehler zu beheben ist folgendes notwendig:
1) Fehlende Pakete mit SUNWcups, SUNWexpect, SUNWnetcat aus dem OpenSolaris Repository nachinstallieren.
2) Die Meldung "sed: command garbled: s/%BACKEND%/3.1.0" kann man durch folgende Änderung beseitigen. Das Problem ist nämlich, dass in einem Script das strings Kommando zwei Zeilen zurückliefert und nicht eine Zeile. Einfach die Datei /opt/NX/bin/nxloadconfig öffnen (zuvor eine Sicherungskopie machen) und folgende Zeile ( bei mir in Zeile 312) wie folgt ändern:
NX_BACKEND_VERSION=$(strings $PATH_BIN/nxagent 2>/dev/null | egrep 'NXAGENT - Version' | sed 's/.*Version //g')
ersetzen durch:
NX_BACKEND_VERSION=$(strings $PATH_BIN/nxagent 2>/dev/null | egrep 'NXAGENT - Version' | sed 's/.*Version //g' | head -n 1)
3) Und zuletzt ist in der Datei /opt/NX/bin/nxnode (zuvor wieder eine Sicherungskopie anlegen) folgende Zeile (direkt nach Zeile 1013 "uniqueid=$(getparam uniqueid)") einzufügen. Das ganze ist ein Workaround für die komischen Unicode-Zeichen anstelle der Buchstaben BCDEF in den Session-Id's. Ich habe nicht näher erforscht, warum die da sind, aber so werden sie korrekt verwendet:
uniqueid=`echo "$uniqueid" | /usr/gnu/bin/tr -d '\357\274' | /usr/gnu/bin/tr '\242\243\244\245\246' 'BCDEF'`Achtung auf die Backticks am Anfang und am Ende!!!
Und dann hat's bei mir funktioniert. Ohne diese Änderungen ist der Client beim Verbinden immer hängengeblieben und wenn man im Internet recherchiert sieht man, dass einige Leute auch diese Probleme haben.
Was kann man nun machen, wenn man auch weiterhin keine Verbindung zustande bringt. In der Datei /opt/NX/bin/nxloadconfig kann man durch folgende Änderung das Debugging in die Datei /var/log/nxserver.log aktivieren:
NX_LOG_LEVEL=0
SESSION_LOG_CLEAN=1
ist zu ersetzen durch:
NX_LOG_LEVEL=6
SESSION_LOG_CLEAN=0
Und dann kann man sich einfach an Hand der Fehlermeldungen durch die einzelnen Scripts hanteln und nach möglichen Fehlern suchen.
Ein Blick in das Blog des Paket-Maintainers (und die Kommentare) auf http://www.kraftek.com/blog/ kann eventuell auch weiterhelfen.
Samstag, 26. September 2009
Mein neuer Home Server auf Basis des Intel SS4200-EHW und OpenSolaris
Nachdem mein alter Linux-Fileserver zu Hause schon etwas in die Jahre gekommen ist und aus allen Nähten platzt habe ich mich dieses Wochenende dazu entschlossen, einen neuen Server auf Basis des "Intel Entry Storage System SS4200-EHW" aufzubauen.
Das SS4200-EHW hat eine 1,6GHz Celeron 420 CPU, 512 MB DDR2 RAM, Platz für 4 Stück 3,5" SATA2-Platten (Nicht Hot-Swap!), 1 Gb LAN, 4 x USB2 und 2 x eSATA. Das Teil wird zB. auch von Fujitsu Siemens für deren Scaleo Home Server verwendet. Optional gibt's den Server auch mit einem vorinstallierten Linux und Software von EMC (SS4200-E).
Da ich mir aber selber das Betriebssystem installieren und konfigurieren will, habe ich die Variante ohne Software gekauft. Beim Auspacken kam dann auch schon mal die erste Überraschung, denn das Stromkabel (ganz normales Kaltgeräte-Kabel) hat sich Intel gespart - egal, habe eh genug davon herumliegen. Dafür war ein Netzwerkkabel dabei.
Da das Teil keine Grafikkarte eingebaut hat, habe ich mich dazu entschlossen, über die serielle Console zu installieren. Man könnte zwar über ein PCIe x1 -> PCIe x16 Riser-Kabel den PCIe x1 Anschluss am Mainboard für eine Grafikkarte nützen, aber das war mir zu aufwendig und ein Server braucht eh keine Grafikkarte. Die erzeugt nur zusätzliche Hitze im System.
Um die serielle Console zu nutzen, muss man einfach den RS232-Anschluss vom Mainboard nach aussen führen. Dazu gibt's im Gehäuse hinten schon die entsprechende Öffnung vorgestanzt, man muss also nur das Kabel am Mainboard anschliessen, das Loch im Gehäuse durchbrechen und den seriellen Stecker am Gehäuse montieren.
Achtung!
Die Belegung der IDC10-Buchse am Mainboard ist nach dem Intel/DTK Layout und nicht wie das gängigere AT/Everex Layout. Ich habe mir das Kabel einfach schnell selber gebaut (Bauteile gibt's zB. beim Conrad um die Ecke). Dazu nimmt man am besten gleich Stecker und Buchsen, die man auf ein Flachbandkabel pressen kann. Vom 10-poligen Flachbandkabel entfernt man dann eine Litze und presst das Kabel auf die IDC10-Buchse und den DB9-Stecker. Die Belegung beim Intel/DTK Layout ist so, dass man das Flachbandkabel einfach raufpressen kann, da ja PIN6 vom DB9 mit PIN2 vom IDC10 verbunden wird, usw.
Anschliessend kann man sich mit einem Nullmodem-Kabel und einer Baudrate von 115200 (8,N,1) zum Server verbinden und nach dem Starten mittels F4 ins BIOS wechseln. Ein paar Screenshots vom BIOS findet man auf http://ss4200.pbworks.com/BIOS-screenshots.
Als Betriebssystem für den Server habe ich mich nach langem Hin-und Her dann für OpenSolaris (x86) entschieden, da ich unbedingt ZFS einsetzen will und mich da nicht auf FUSE-ZFS unter Linux einlassen will.
ZFS hat für mich unter anderem folgende Vorteile:
Die Installation von OpenSolaris geht dann wie folgt:
1) OpenSolaris 2009.06 Live-CD in ein externes USB CD-Laufwerk einlegen und im BIOS die Bootreihenfolge entsprechend ändern.
2) Leider unterstützt die Live-CD nicht die serielle Console, sondern gibt alles auf der Grafikkarte aus. Dazu kann man im BIOS nun einfach die On-Board Grafikkarte aktivieren (wahlweise mit 1MB oder 8MB Speicher - 1MB reicht vollkommen) - jedoch hat man ja keinen VGA-Anschluss am Server. Die Lösung dazu ist, dass man in den Text-Modus der Live-CD bootet und dann den SSH-Daemon startet und sich anschliessend remote einloggt. Da man das im Blindflug über eine USB-Tastatur machen muss, schaut man sich das am besten einmal vorher auf einem anderen Rechner (mit Grafikkarte) an und notiert sich die Tasten, die man drücken muss (und wie man den Zeitpunkt erkennt, dass man etwas eingeben muss - sieht man aber ganz einfach an der nicht mehr blinkenden LED des CD-Laufwerkes).
Die Tasten sind (danach muss klarerweise immer Enter gedrückt werden):
2x Cursor down beim Grub-Screen (um die Boot-Option Text Console zu aktivieren). Ein paar Sekunden später dann 15 und 8 um die Sprache und das Gebietsschema auszuwählen. Wenn das System fertig gebootet hat, kann man sich mit dem User jack und dem Passwort jack einloggen. Anschliessend "su root" und das Passwort opensolaris. Nach der Eingabe von "svcadm enable ssh" startet der SSH-Daemon. Damit das ganze funktioniert, muss der Server per DHCP eine IP-Adresse im Netzwerk bezogen haben.
3) Nun kann man sich von einem anderen Rechner aus per "ssh -Y jack@1.2.3.4" zum Server verbinden (1.2.3.4 ist durch die IP des Servers zu ersetzen). In der Shell muss man dann wieder root werden und mit "/bin/gui-install" kann man dann den grafischen Installer starten.
"ssh -Y" deshalb, da zumindest bei mir mit "ssh -X" folgender Fehler auftrat:
4) Nach dem Reboot wird man feststellen, dass man noch immer nichts auf der seriellen Konsole sehen bzw. man sich auch nicht einloggen kann. Das hat unter anderem damit zu tun, dass wir nur einen seriellen Port haben und OpenSolaris standardmässig den zweiten seriellen Port für Console-Logins konfiguriert. Es sind daher nun folgende Änderungen notwendig (wieder per ssh über das Netzwerk einloggen und als root durchführen):
In der Datei "/etc/remote" folgendes einfügen:
Danach ein "reboot" durchführen und schon sieht man die Boot-Meldungen auf der Console und man kann sich auch von der Console aus einloggen.
Das einzige Problem ist noch, dass man fürs BIOS eine Baudrate von 115200 hat und für Solaris eine Baudrate von 9600. Ich habe dazu einfach im BIOS die Baudrate auf 9600 heruntergesetzt, da ich diese standardmässig auch auf anderen Systemen verwende. Man kann aber natürlich auch im Solaris die höhere Baudrate mitangeben.
Abschliessend habe ich dann im BIOS auch die OnBoard-Grafikkarte deaktiviert, da ich jeden MB RAM im Server selber brauche ;-)
Das war's dann fürs erste auch schon, innerhalb kürzester Zeit hat man so ein OpenSolaris auf einem SS4200-EHW ganz ohne Grafikkarte installiert.
Übrigens installiert sich das OpenSolaris automatisch in einen ZFS Root-Pool (belegt dort ca. 3GB) und legt dann nach der Installation auch gleich einen Snapshot an. Sehr praktisch.
Abschliessend ist noch zu sagen, dass der Server Super-Leise ist (abgesehen von ein paar Sekunden beim Start, wo die Lüfter mal kurz mit Volldampf durchs Gehäuse blasen). Ich habe ihn zur Zeit in einer Ecke im Wohnzimmer stehen und man hört gar nix.
Das SS4200-EHW hat eine 1,6GHz Celeron 420 CPU, 512 MB DDR2 RAM, Platz für 4 Stück 3,5" SATA2-Platten (Nicht Hot-Swap!), 1 Gb LAN, 4 x USB2 und 2 x eSATA. Das Teil wird zB. auch von Fujitsu Siemens für deren Scaleo Home Server verwendet. Optional gibt's den Server auch mit einem vorinstallierten Linux und Software von EMC (SS4200-E).
Da ich mir aber selber das Betriebssystem installieren und konfigurieren will, habe ich die Variante ohne Software gekauft. Beim Auspacken kam dann auch schon mal die erste Überraschung, denn das Stromkabel (ganz normales Kaltgeräte-Kabel) hat sich Intel gespart - egal, habe eh genug davon herumliegen. Dafür war ein Netzwerkkabel dabei.
Da das Teil keine Grafikkarte eingebaut hat, habe ich mich dazu entschlossen, über die serielle Console zu installieren. Man könnte zwar über ein PCIe x1 -> PCIe x16 Riser-Kabel den PCIe x1 Anschluss am Mainboard für eine Grafikkarte nützen, aber das war mir zu aufwendig und ein Server braucht eh keine Grafikkarte. Die erzeugt nur zusätzliche Hitze im System.
Um die serielle Console zu nutzen, muss man einfach den RS232-Anschluss vom Mainboard nach aussen führen. Dazu gibt's im Gehäuse hinten schon die entsprechende Öffnung vorgestanzt, man muss also nur das Kabel am Mainboard anschliessen, das Loch im Gehäuse durchbrechen und den seriellen Stecker am Gehäuse montieren.
Achtung!
Die Belegung der IDC10-Buchse am Mainboard ist nach dem Intel/DTK Layout und nicht wie das gängigere AT/Everex Layout. Ich habe mir das Kabel einfach schnell selber gebaut (Bauteile gibt's zB. beim Conrad um die Ecke). Dazu nimmt man am besten gleich Stecker und Buchsen, die man auf ein Flachbandkabel pressen kann. Vom 10-poligen Flachbandkabel entfernt man dann eine Litze und presst das Kabel auf die IDC10-Buchse und den DB9-Stecker. Die Belegung beim Intel/DTK Layout ist so, dass man das Flachbandkabel einfach raufpressen kann, da ja PIN6 vom DB9 mit PIN2 vom IDC10 verbunden wird, usw.
Anschliessend kann man sich mit einem Nullmodem-Kabel und einer Baudrate von 115200 (8,N,1) zum Server verbinden und nach dem Starten mittels F4 ins BIOS wechseln. Ein paar Screenshots vom BIOS findet man auf http://ss4200.pbworks.com/BIOS-screenshots.
Als Betriebssystem für den Server habe ich mich nach langem Hin-und Her dann für OpenSolaris (x86) entschieden, da ich unbedingt ZFS einsetzen will und mich da nicht auf FUSE-ZFS unter Linux einlassen will.
ZFS hat für mich unter anderem folgende Vorteile:
- Einfach Handhabung
- Datensicherheit durch Erkennung von Silent Data Corruption
- Demnächst Unterstützung von Data Deduplication
- Snapshots und Clones
- Data Compression
Die Installation von OpenSolaris geht dann wie folgt:
1) OpenSolaris 2009.06 Live-CD in ein externes USB CD-Laufwerk einlegen und im BIOS die Bootreihenfolge entsprechend ändern.
2) Leider unterstützt die Live-CD nicht die serielle Console, sondern gibt alles auf der Grafikkarte aus. Dazu kann man im BIOS nun einfach die On-Board Grafikkarte aktivieren (wahlweise mit 1MB oder 8MB Speicher - 1MB reicht vollkommen) - jedoch hat man ja keinen VGA-Anschluss am Server. Die Lösung dazu ist, dass man in den Text-Modus der Live-CD bootet und dann den SSH-Daemon startet und sich anschliessend remote einloggt. Da man das im Blindflug über eine USB-Tastatur machen muss, schaut man sich das am besten einmal vorher auf einem anderen Rechner (mit Grafikkarte) an und notiert sich die Tasten, die man drücken muss (und wie man den Zeitpunkt erkennt, dass man etwas eingeben muss - sieht man aber ganz einfach an der nicht mehr blinkenden LED des CD-Laufwerkes).
Die Tasten sind (danach muss klarerweise immer Enter gedrückt werden):
2x Cursor down beim Grub-Screen (um die Boot-Option Text Console zu aktivieren). Ein paar Sekunden später dann 15 und 8 um die Sprache und das Gebietsschema auszuwählen. Wenn das System fertig gebootet hat, kann man sich mit dem User jack und dem Passwort jack einloggen. Anschliessend "su root" und das Passwort opensolaris. Nach der Eingabe von "svcadm enable ssh" startet der SSH-Daemon. Damit das ganze funktioniert, muss der Server per DHCP eine IP-Adresse im Netzwerk bezogen haben.
3) Nun kann man sich von einem anderen Rechner aus per "ssh -Y jack@1.2.3.4" zum Server verbinden (1.2.3.4 ist durch die IP des Servers zu ersetzen). In der Shell muss man dann wieder root werden und mit "/bin/gui-install" kann man dann den grafischen Installer starten.
"ssh -Y" deshalb, da zumindest bei mir mit "ssh -X" folgender Fehler auftrat:
The program 'gui-install' received an X Window System error.Die weitere Installation verläuft dann ganz einfach:
This probably reflects a bug in the program.
The error was 'BadAtom (invalid Atom parameter)'.
(Details: serial 630 error_code 5 request_code 20 minor_code 0)
(Note to programmers: normally, X errors are reported asynchronously;
that is, you will receive the error a while after causing it.
To debug your program, run it with the --sync command line
option to change this behavior. You can then get a meaningful
backtrace from your debugger if you break on the gdk_x_error() function.)
4) Nach dem Reboot wird man feststellen, dass man noch immer nichts auf der seriellen Konsole sehen bzw. man sich auch nicht einloggen kann. Das hat unter anderem damit zu tun, dass wir nur einen seriellen Port haben und OpenSolaris standardmässig den zweiten seriellen Port für Console-Logins konfiguriert. Es sind daher nun folgende Änderungen notwendig (wieder per ssh über das Netzwerk einloggen und als root durchführen):
In der Datei "/etc/remote" folgendes einfügen:
console:\In der Datei "/rpool/boot/grub/menu.lst" folgende Zeilen löschen oder auskommentieren (mit einem # am Anfang):
:dv=/dev/term/a:br#9600:el=^C^S^Q^U^D:ie=%$:oe=^D:
splashimage /boot/grub/splash.xpm.gzWeiter unten ist dann auch noch die Kernel-Zeile:
background 215ECA
splashimage /boot/solaris.xpm
foreground d25f00
background 115d93
kernel$ /platform/i86pc/kernel/$ISADIR/unix -B $ZFS-BOOTFS,console=graphicsdurch
kernel$ /platform/i86pc/kernel/$ISADIR/unix -B $ZFS-BOOTFS,console=ttyazu ersetzen. Bei der Gelegenheit kann man das Grub-Timeout (timeout 30) auch gleich von 30 Sekunden auf eine kürzere Zeit runtersetzen.
Danach ein "reboot" durchführen und schon sieht man die Boot-Meldungen auf der Console und man kann sich auch von der Console aus einloggen.
Das einzige Problem ist noch, dass man fürs BIOS eine Baudrate von 115200 hat und für Solaris eine Baudrate von 9600. Ich habe dazu einfach im BIOS die Baudrate auf 9600 heruntergesetzt, da ich diese standardmässig auch auf anderen Systemen verwende. Man kann aber natürlich auch im Solaris die höhere Baudrate mitangeben.
Abschliessend habe ich dann im BIOS auch die OnBoard-Grafikkarte deaktiviert, da ich jeden MB RAM im Server selber brauche ;-)
Das war's dann fürs erste auch schon, innerhalb kürzester Zeit hat man so ein OpenSolaris auf einem SS4200-EHW ganz ohne Grafikkarte installiert.
Übrigens installiert sich das OpenSolaris automatisch in einen ZFS Root-Pool (belegt dort ca. 3GB) und legt dann nach der Installation auch gleich einen Snapshot an. Sehr praktisch.
root@homeserver:~# zfs list -t snapshot
NAME USED AVAIL REFER MOUNTPOINT
rpool/ROOT/opensolaris@install 146M - 2.82G -
Abschliessend ist noch zu sagen, dass der Server Super-Leise ist (abgesehen von ein paar Sekunden beim Start, wo die Lüfter mal kurz mit Volldampf durchs Gehäuse blasen). Ich habe ihn zur Zeit in einer Ecke im Wohnzimmer stehen und man hört gar nix.
Dienstag, 22. September 2009
Wo sind denn meine Applikationen?
Jetzt ist es schon über 2 Wochen her, dass es die neue H8-Firmware für das Samsung Galaxy gibt und es ist leider noch immer nicht möglich, dass man damit kopiergeschützte Applikationen aus dem Market laden kann (das betrifft sowohl Gratis- als auch Bezahl-Applikationen).
Die Wurzel des Übels liegt darin, dass bestimmte Handys keine kopiergeschützten Applikationen aus dem Market laden dürfen (zB. das Android Dev Phone), da Google offenbar befürchtet das man mit einem root-Zugriff, den ja das Dev Phone standardmässig hat, eventuell den Kopierschutz knackt. (Quelle: http://asia.cnet.com/crave/2009/02/27/google-blocks-access-to-paid-android-apps-on-developer-phones/).
Das Ausgrenzen von Telefonen ist nun aber leider offenbar mittels einer Whitelist implementiert, dh. in der Liste stehen alle Handytypen (inkl. Firmware), die auf kopiergeschützte Applikationen zugreifen dürfen und ich wollte jetzt einfach nicht mehr länger warten, bis Google die neue Firmware für den Market freigibt.
Bei Google gibt's dazu einen Thread auf: http://www.google.com/support/forum/p/Android+Market/thread?tid=40c93958284cafac&hl=en#all. Dort steht zwar von einem Google-Mitarbeiter der Satz "We made a change today that should fix accessibility issues for some Samsung Galaxy and HTC users." (Datum: 14.9.2009), aber bei mir funktioniert's auch heute noch immer nicht.
Irgendwie ist das ganze doch sehr schlecht zwischen Samung und Google koordiniert. Meiner Meinung nach sollte man die Firmware zuerst im Market freigeben und erst dann an die User ausrollen.
Egal, ich bin ja eh root und mit folgendem Workaround kann man dem Market eine alte Firmware vorgaukeln:
0) Es gilt wie immer:
Ich übernehme keine Garantie auf alles was da jetzt steht bzw. die verlinkten Downloads!
1) Booten im Recovery Modus (Ich habe inzwischen das Recovery Image von http://forum.hdblog.it/showthread.php?t=3995 auf meinem Gerät, das gefällt mir in Summe besser. Allerdings verwende ich die darin enthaltenen "enable/disable root" Funktionen nicht, da mir die darin verwendete su-Version vom Konzept her nicht gefällt.)
2) System-Filesystem mit adb remount im Read/Write Modus remounten
3) In die Shell mittels adb shell einsteigen
4) Eine Sicherungskopie der Original-Konfiguration mittels cp /system/build.prop /system/build.prop.orig erstellen
5) Editor mit vi /system/build.prop öffnen
6) In die Zeile 27 navigieren (vi-Kommando ESC:27 [dh. zuerst Taste ESC, dann Taste :, dann Taste 2 und dann Taste 7 drücken]), dort steht dann:
8) Das ganze nochmals mit cat build.prop | grep fingerprint | grep Samsung kontrollieren und dort sollte nun folgendes stehen:
10) Abschliessend dann das Handy mit sync;reboot neu starten und nach ein paar Stunden sind die kopiergeschützten Applikationen wieder im Market verfügbar. Es wird da anscheindend auch am Market-Server irgendwo etwas gecacht oder eventuell wird die Firmware-Info nicht laufend überprüft.
Weiters habe ich auch mal den Hinweis gelesen, dass man nach der Aktion erstmalig auch über GSM/3G und nicht über WLAN in den Market einsteigen muss.
Testen kann man das ganze, in dem man zB. nach den Applikationen "ColorDict" oder "Twidroid PRO" sucht.
Mal schauen, wie lange es noch dauern wird, bis Google die Firmware endlich freigibt und man wieder den originalen Wert im build.prop verwenden kann.
Fazit:
Den ganzen Whitelist-Hokuspokus könnte sich Google überhaupt schenken, weil man damit ja offensichtlich die root-Handys teilweise aussperren will, aber man das ganze eben genau auf diesen Geräten mit einem simplen Workaround umgehen kann.
Die Wurzel des Übels liegt darin, dass bestimmte Handys keine kopiergeschützten Applikationen aus dem Market laden dürfen (zB. das Android Dev Phone), da Google offenbar befürchtet das man mit einem root-Zugriff, den ja das Dev Phone standardmässig hat, eventuell den Kopierschutz knackt. (Quelle: http://asia.cnet.com/crave/2009/02/27/google-blocks-access-to-paid-android-apps-on-developer-phones/).
Das Ausgrenzen von Telefonen ist nun aber leider offenbar mittels einer Whitelist implementiert, dh. in der Liste stehen alle Handytypen (inkl. Firmware), die auf kopiergeschützte Applikationen zugreifen dürfen und ich wollte jetzt einfach nicht mehr länger warten, bis Google die neue Firmware für den Market freigibt.
Bei Google gibt's dazu einen Thread auf: http://www.google.com/support/forum/p/Android+Market/thread?tid=40c93958284cafac&hl=en#all. Dort steht zwar von einem Google-Mitarbeiter der Satz "We made a change today that should fix accessibility issues for some Samsung Galaxy and HTC users." (Datum: 14.9.2009), aber bei mir funktioniert's auch heute noch immer nicht.
Irgendwie ist das ganze doch sehr schlecht zwischen Samung und Google koordiniert. Meiner Meinung nach sollte man die Firmware zuerst im Market freigeben und erst dann an die User ausrollen.
Egal, ich bin ja eh root und mit folgendem Workaround kann man dem Market eine alte Firmware vorgaukeln:
0) Es gilt wie immer:
Ich übernehme keine Garantie auf alles was da jetzt steht bzw. die verlinkten Downloads!
1) Booten im Recovery Modus (Ich habe inzwischen das Recovery Image von http://forum.hdblog.it/showthread.php?t=3995 auf meinem Gerät, das gefällt mir in Summe besser. Allerdings verwende ich die darin enthaltenen "enable/disable root" Funktionen nicht, da mir die darin verwendete su-Version vom Konzept her nicht gefällt.)
2) System-Filesystem mit adb remount im Read/Write Modus remounten
3) In die Shell mittels adb shell einsteigen
4) Eine Sicherungskopie der Original-Konfiguration mittels cp /system/build.prop /system/build.prop.orig erstellen
5) Editor mit vi /system/build.prop öffnen
6) In die Zeile 27 navigieren (vi-Kommando ESC:27 [dh. zuerst Taste ESC, dann Taste :, dann Taste 2 und dann Taste 7 drücken]), dort steht dann:
ro.build.fingerprint=Samsung/GT-I7500/GT-I7500/GT-I7500:1.5/CUPCAKE/83:user/ota-rel-keys,release-keys7) Die Zahl 83 ist nun gegen die Zahl für eine ältere Firmware-Version zu ersetzen (zB. 12). Achtung, bei mir hat das Navigieren mit den Cursor-Tasten im vi nicht richtig funktioniert, aber mit den Tasten h,j,k,l (für Links, Runter, Rauf und Rechts) hat's problemlos geklappt. Also mit der l-Taste bis zum 8'er von 83 navigieren, danach ESCxxESCi12ESCZZ und schon hat man den neuen Wert gespeichert (Bei Problemen im vi einfach mit ESC:q! aussteigen und nochmals von vorne beginnen).
8) Das ganze nochmals mit cat build.prop | grep fingerprint | grep Samsung kontrollieren und dort sollte nun folgendes stehen:
ro.build.fingerprint=Samsung/GT-I7500/GT-I7500/GT-I7500:1.5/CUPCAKE/12:user/ota-rel-keys,release-keys9) Danach muss noch der Cache für den Market gelöscht werden. Dazu muss man mit mount /dev/block/mmcblk0p1 /data das data-Filesystem mounten und mit cd /data/data/com.android.vending/cache/ in das Cache-Verzeichnis wechseln und mit rm -f * dann den Cache löschen.
10) Abschliessend dann das Handy mit sync;reboot neu starten und nach ein paar Stunden sind die kopiergeschützten Applikationen wieder im Market verfügbar. Es wird da anscheindend auch am Market-Server irgendwo etwas gecacht oder eventuell wird die Firmware-Info nicht laufend überprüft.
Weiters habe ich auch mal den Hinweis gelesen, dass man nach der Aktion erstmalig auch über GSM/3G und nicht über WLAN in den Market einsteigen muss.
Testen kann man das ganze, in dem man zB. nach den Applikationen "ColorDict" oder "Twidroid PRO" sucht.
Mal schauen, wie lange es noch dauern wird, bis Google die Firmware endlich freigibt und man wieder den originalen Wert im build.prop verwenden kann.
Fazit:
Den ganzen Whitelist-Hokuspokus könnte sich Google überhaupt schenken, weil man damit ja offensichtlich die root-Handys teilweise aussperren will, aber man das ganze eben genau auf diesen Geräten mit einem simplen Workaround umgehen kann.
Abonnieren
Posts (Atom)
Posts
