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:

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:
  • Einfach Handhabung
  • Datensicherheit durch Erkennung von Silent Data Corruption
  • Demnächst Unterstützung von Data Deduplication
  • Snapshots und Clones
  • Data Compression
Da für eine OpenSolaris ZFS Installation eine RAM-Größe >= 768 MB empfohlen wird habe ich dem Server auch noch einen Standard 2GB DDR2 Riegel spendiert.

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.
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.)
Die weitere Installation verläuft dann ganz einfach:









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:\
:dv=/dev/term/a:br#9600:el=^C^S^Q^U^D:ie=%$:oe=^D:
In der Datei "/rpool/boot/grub/menu.lst" folgende Zeilen löschen oder auskommentieren (mit einem # am Anfang):
splashimage /boot/grub/splash.xpm.gz
background 215ECA

splashimage /boot/solaris.xpm
foreground d25f00
background 115d93
Weiter unten ist dann auch noch die Kernel-Zeile:
kernel$ /platform/i86pc/kernel/$ISADIR/unix -B $ZFS-BOOTFS,console=graphics
durch
kernel$ /platform/i86pc/kernel/$ISADIR/unix -B $ZFS-BOOTFS,console=ttya
zu 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:
ro.build.fingerprint=Samsung/GT-I7500/GT-I7500/GT-I7500:1.5/CUPCAKE/83:user/ota-rel-keys,release-keys
7) 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-keys
9) 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.

Mittwoch, 16. September 2009

Wo ist denn nur mein Android Launcher?

Nachdem ich mich heute mal wieder über die 3-Screens Limitierung des aktuellen Android Launchers (Startseite) geärgert habe, ist es mir nach einigen Experimenten mit diversen alternativen Launchern gelungen, dass mein originaler Launcher überhaupt nicht mehr gestartet ist.

Die Ursache war, dass ich aus reiner Neugierde ein Launcher Replacement (ersetzt den originalen Android Launcher) ausprobiert habe und bei dem stand ungefähr die folgende Anleitung:

Installation (im Recovery Mode):
1) Anlegen einer Kopie von /system/app/Launcher.apk
2) Installation des neuen Launcher.apk
3) Löschen von /system/app/Launcher.odex

Deinstallation:
1) Zuvor erstellte Kopie von Launcher.apk nach /system/app/Launcher.apk kopieren

OK, klang irgendwie logisch und ich dachte mir, die Launcher.odex wird dynamisch erzeugt, weil ja die anderen Anwendungen auch immer nur als apk-Paket ausgeliefert werden.

Leider blieb das Handy dann aber nach der Deinstallation beim Android Schriftzug hängen und mein erster Gedanke dazu war: Verdammt, jetzt kann ich das Handy nochmals komplett flashen und muss wieder alles neu konfigurieren.

Die Ursache des Problems war mit einem adb logcat jedoch rasch gefunden, das Android beschwerte sich wie folgt über die fehlende Datei Launcher.odex:

I/PackageManager( 1058): /system/app/Launcher.apk changed; unpacking
I/dalvikvm( 1058): Zip is good, but no classes.dex inside, and no .odex file in the same directory
W/PackageManager( 1058): Exception reading apk: /system/app/Launcher.apk
W/PackageManager( 1058): java.io.IOException: /system/app/Launcher.apk
W/PackageManager( 1058): at dalvik.system.DexFile.isDexOptNeeded(Native Method)
W/PackageManager( 1058): at com.android.server.PackageManagerService.scanPackageLI(PackageManagerService.java:2138)
W/PackageManager( 1058): at com.android.server.PackageManagerService.scanPackageLI(PackageManagerService.java:1793)
W/PackageManager( 1058): at com.android.server.PackageManagerService.scanDirLI(PackageManagerService.java:1705)
W/PackageManager( 1058): at com.android.server.PackageManagerService.(PackageManagerService.java:460)
W/PackageManager( 1058): at com.android.server.PackageManagerService.main(PackageManagerService.java:261)
W/PackageManager( 1058): at com.android.server.ServerThread.run(SystemServer.java:113)

Super, die Launcher.odex habe ich aber ein paar Minuten vorher gelöscht und hatte kein Backup.

Was ist nun diese odex-Datei überhaupt? Auf http://groups.google.com/group/android-framework/browse_thread/thread/70ee61a240edc84a steht die folgende Erklärung:
The production builds pre-generate the .odex files from the source apk/jar files, and then remove the "classes.dex" from the source. This uses a bit more space on /system (because the DEX data isn't compressed) but saves space on /data (because we don't need to hold the odex data in /data/dalvik-cache).
Auf Deutsch heisst dass nun, wenn eine .odex Datei existiert, dann ist in dem Zuge der Erstellung dieser Datei das "classes.dex" aus dem apk-Paket entfernt worden, dh. man braucht beide Dateien, damit die Applikation lauffähig ist. Wenn das classes.dex noch im apk-Paket enthalten ist, dann werden normalerweise die odex-Daten in /data/dalvik-cache abgelegt. Die heissen dann zB. /data/dalvik-cache/system@app@YouTube.apk@classes.dex für die Applikation in /system/app/YouTupe.apk.

Wie komme ich aber nun wieder zu dieser Launcher.odex, die zu meiner Launcher.apk passt?

Glücklicherweise habe ich ja erst vor ein paar Tagen mein Galaxy auf das neue H8 Image von Samsung geflasht und hatte daher noch das entsprechende Update-File am Rechner. Das File gibt's zum Beispiel auch auf http://www.android-hilfe.de/root-hacking-modding-fuer-samsung-galaxy/6010-fuer-profis-updates-und-customroms-fuer-galaxy-mit-odin-mulit-downloader-einspielen.html).
In dem ZIP-File für das Update ist ein Tar-File "I7500XXIH8-PDA-CL53973-REV5(VIA).tar" mit folgendem Inhalt enthalten:
  • amss
  • cache.img
  • kernel
  • recovery
  • system
Das gesuchte Launcher.odex ist ja in der system-Partition und daher vermutlich in der Datei "system". Mit dem Tool unyaffs von http://code.google.com/p/unyaffs/ lassen sich nun unter Linux ganz einfach alle Files aus dem system-Image extrahieren. Danach einfach die Launcher.odex wieder auf das Handy nach /system/app kopieren, rebooten und alles läuft wieder wie vorher.

Nachem ich jetzt weiss wo ich die originalen Files wieder herbekomme steht nun weiteren root-Experimenten nichts mehr im Wege ;-)