Android sdk ohne Android Studio auf Ubuntu 17.04

Geschrieben von everflux am Juni 3rd, 2017

Google hat mit der Wahl der Jetbrains Platform für ihr Android Studio eine gute Wahl gemacht. (Auch wenn ich mir persönlich gewünscht hätte, dass es NetBeans wird, aber das war bei dem Verhalten von Oracle ja kaum zu erwarten.) Dennoch gibt es ab und zu Gründe, ohne Android Studio eine Installation der Android Entwicklungswerkzeuge vorzunehmen. (Zum Beispiel, wenn man NativeScript nutzt und dabei in WebStorm unterwegs ist…)

Nach der Umstellung des SDK ist es schwierig, aktuelle Anleitungen für Ubuntu zu finden, die nicht mit „Download Android Studio…“ beginnen.

Darum hier jetzt meine Kurzanleitung:

  1. Auf 64bit Systemen wird noch immer eine 32bit Umgebung benötigt, diese installiert man mittels
    sudo apt-get install lib32ncurses5 lib32stdc++6 libstdc++6
  2. Ordner anlegen, wo das Android SDK und die Werkzeuge landen sollen, ich wähle mal
    mkdir ~/tools/android-sdk<c/ode>
  3. Download der Kommandozeilen Werkzeuge des SDK
    wget https://dl.google.com/android/repository/sdk-tools-linux-3859397.zip
  4. Das wird dann unter ~/tools/android-sdk ausgepackt, entstehen wird danach der Ordner „tools“
  5. Die entstehenden Android Verzeichnisse werden in den PATH aufgenommen, damit von der Kommandozeile die Programme gefunden werden. Ob das jetzt in die ~/.bashrc oder ~/.zshrc oder ~/.sonstwasrc muss, wird jeder selbst wissen.

    export ANDROID_HOME=~/tools/android-sdk
    export PATH=$PATH:$ANDROID_HOME/emulator:$ANDROID_HOME/tools:$ANDROID_HOME/tools/bin:$ANDROID_HOME/platform-tools
  6. Nun folgt ein umfangreicherer Download….

    sdkmanager --update
    sdkmanager "extras;android;m2repository" "extras;google;m2repository" "system-images;android-25;google_apis;x86" "system-images;android-25;google_apis;x86_64" "platforms;android-25" "build-tools;25.0.3"
  7. Und „schon“ kann ein Android Emulator Image instantiiert werden
    avdmanager create avd -d 9 --abi google_apis/x86 --name nexus5x  -k "system-images;android-25;google_apis;x86"
  8. Gestartet wird das ganze dann z.B. so:
    emulator @nexus5x -skin 768x1280

Schon ist das Android SDK Setup unter Ubuntu fertig.

Leider stehen einige Optionen, wie „–skin“ bei dem avdmanager (noch) nicht zur Verfügung, so dass beim Emulator Start der Parameter mit angegeben werden muss. Sonst gibt es ein Guckloch im Format einer Briefmarke für den Emulator…

StartCOM mit API für StartSSL

Geschrieben von everflux am April 29th, 2016

Let’s encrypt hat es vorgemacht, jetzt zieht der Let’s encrypt Partner StartCOM nach: Neuerdings gibt es eine API! Damit ist es deutlich einfacher, neue Zertifikate in einem automatisierten Prozess zu erhalten.

Laut Webseite ist die API auch für die kostenlosen Domain-Validated Zertifikate nutzbar, jedoch auf 5 Domains beschränkt. Für die meisten privaten Nutzer sollte das mehr als ausreichend sein. Im Gegensatz zu Let’s encrypt Zertifikaten sind die StartCOM StartSSL Zertifikate ein Jahr gültig, so dass es seltener nötig ist, neue Zertifikate zu holen.

Infos im Blogpost von StartSSL: https://startssl.com/NewsDetails?date=20160428 direkt zur API geht es hier: https://startssl.com/startapi

Gelöschte Datei retten solange sie offen ist

Geschrieben von everflux am Juli 13th, 2014

Durch eine unglueckliche Konstellation kam es dazu, dass mir von laufenden, produktiven, KVM Maschinen die Images abhanden kamen. Kurzum: Gelöscht. Aber da die Maschinen noch liefen eine gute Gelegenheit sich an der Rettung zu versuchen, und nicht über ein Backup zu arbeiten.
Dadurch, dass die Datei Images noch in Benutzung waren, war ein File-Handle mit dem jeweiligen Prozess verknüpft. Dieser kann nach Belieben noch mit der Datei arbeiten, auch das Dateisystem betrachtet die zu der Datei gehörenden Datenblöcke nicht als frei und bewahrt sie somit vor Verlust. Solange der Prozess läuft aber nur.

Zur Illustration verwenden wir einmal folgende Kommandos:

wget --limit-rate=1000 http://releases.ubuntu.com/14.04/ubuntu-14.04-desktop-amd64.iso

Der Download ist extra langsam gedreht, so dass genug Zeit ist zum experimentieren.
Nun loeschen wir die Datei – das wget laeuft weiter.

rm ubuntu-14.04-desktop-amd64.iso

Suchen wir nun nach Prozessen, die auf gelöschte Dateien zugreifen und filtern nach Dateien mit dem Wort „ubuntu“:

lsof | grep deleted | grep ubuntu
wget 10694 tkruse 4w REG 252,1 195943 1573596 /home/tkruse/ubuntu-14.04-desktop-amd64.iso (deleted)

Der einfachste Weg den Inhalt zu retten wäre nun, einfach die Datei(inhalte) zu kopieren. Dazu suchen wir das Filehandle des Prozesses „10694“ (dem wget aus dem lsof)


ls -l /proc/10694/fd             
total 0
lrwx------ 1 tkruse tkruse 64 Jul 12 13:02 0 -> /dev/pts/7
lrwx------ 1 tkruse tkruse 64 Jul 12 13:02 1 -> /dev/pts/7
lrwx------ 1 tkruse tkruse 64 Jul 12 13:02 2 -> /dev/pts/7
lrwx------ 1 tkruse tkruse 64 Jul 12 13:02 3 -> socket:[797560]
l-wx------ 1 tkruse tkruse 64 Jul 12 13:02 4 -> /home/tkruse/ubuntu-14.04-desktop-amd64.iso.1 (deleted)

Das Datei handle können wir als Quelle nehmen, und den Inhalt nun kopieren:

cp /proc/10694/fd/4 /home/tkruse/rescue

Da die Maschinen noch laufen, wäre es eigentlich schön nicht einen Zustand zu kopieren, sondern die Datei auf ’nicht gelöscht‘ setzen zu können. Das ging mal mit ln -L, wurde jedoch aus Sicherheitsgründen aus dem Kernel entfernt.

Dazu kann man nur noch direkt ins Dateisystem eingreifen. Nichts für Angsthasen – und ein fsck sollte danach besser stattfinden.
Mittels debugfs kann man einen neuen Link auf die inode der Datei anlegen. Darüber kann danach wieder ein Zugriff erfolgen. Jedoch wird dabei der Link-Count nicht erhöht, so dass die Datei nicht wirklich wieder hergestellt ist.
Die inode ist die Zahl aus dem lsof vor dem Dateipfad, in diesem Fall „1573596“. Legen wir also eine neue Datei an, die diese inode nutzt:

sudo debugfs -w /dev/mapper/ubuntu--gnome--vg-root -R "link <1573596> rescue"

Anschließend kann man den Prozess, der die Datei bisher noch offen und damit am Leben gehalten hat, beenden und die Datei (auf ein anderes Dateisystem) kopieren.

cp rescue ....

Ist man damit fertig, kann man den Link wieder aufheben.

sudo debugfs -w /dev/mapper/ubuntu--gnome--vg-root -R "unlink rescue"

Durch durch das debugfs ist es im Prinzip auch möglich den Linkcount zu reparieren, das war mir jedoch etwas zu warm. Auch bin ich nicht sicher, wie es sich mit dem „gelöscht“ Flag tatsächlich verhält, so dass ich die Daten dann auf ein anderes Dateisystem kopiert habe (um versehentliches überschreiben zu verhindern), das betroffene Dateisystem ausgehängt und per fsck geprüft habe.
Soweit ich das beurteilen kann: Die Datei wurde perfekt gerettet und alles läuft mit minimaler Downtime weiter.

Diagnose mit sysdig

Geschrieben von everflux am Mai 17th, 2014

Wäre es nicht fantastisch, wenn es ein Tool gäbe, dass wie tcpdump auf System-Ebene arbeitet? Vielleicht noch gemischt mit lsof. Und strace. Und das ganze vielleicht auch so dass man im Nachhinein filtern kann!

Das gibt es. Es nennt sich „sysdig“ und ist OpenSource: http://www.sysdig.org/ bzw. https://github.com/draios/sysdig/

Die Installation auf einem Ubuntu 14.04 sollte eigentlich so funktionieren:

curl -s https://s3.amazonaws.com/download.draios.com/stable/install-sysdig | sudo bash

Das hat leider nicht ganz geklappt:

curl -s https://s3.amazonaws.com/download.draios.com/stable/install-sysdig | sudo bash
[sudo] password for tkruse:
* Detecting operating system
* Installing Draios public key
OK
* Installing Draios repository
* Installing kernel headers
E: Package 'linux-headers-3.11.0-12-generic' has no installation candidate
Unable to find kernel development files for the current kernel version 3.11.0-12-generic
This usually means that your system is not up-to-date or you installed a custom kernel version.
The installation will continue but you'll need to install these yourself in order to use sysdig.
Please write to the mailing list at https://groups.google.com/forum/#!forum/sysdig
if you need further assistance.
* Installing Sysdig
Selecting previously unselected package sysdig.
(Reading database ... 207643 files and directories currently installed.)
Preparing to unpack .../sysdig_0.1.82_amd64.deb ...
Unpacking sysdig (0.1.82) ...
Processing triggers for man-db (2.6.7.1-1) ...
Setting up sysdig (0.1.82) ...
Loading new sysdig-0.1.82 DKMS files...
First Installation: checking all kernels...
Building only for 3.11.0-12-generic
Module build for the currently running kernel was skipped since the
kernel source for this kernel does not seem to be installed.

Offenbar war mein Kernel nicht beim Update auf Ubuntu 14.04 mitgezogen worden:

uname -a
Linux charix 3.11.0-12-generic #19-Ubuntu SMP Wed Oct 9 16:20:46 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux

Dafuer gab es keine Kernel-Header mehr, so dass die sysdig Module nicht kompiliert und installiert werden konnten.
Das ist schnell zu beheben, neuer Kernel und neue Header:

sudo apt-get install linux-image-3.13.0-24-generic
sudo dpkg-reconfigure sysdig
Removing old sysdig-0.1.82 DKMS files...

-------- Uninstall Beginning --------
Module: sysdig
Version: 0.1.82
Kernel: 3.13.0-24-generic (x86_64)
-------------------------------------

Status: Before uninstall, this module version was ACTIVE on this kernel.

sysdig-probe.ko:
- Uninstallation
- Deleting from: /lib/modules/3.13.0-24-generic/updates/dkms/
- Original module
- No original module was found for this module on this kernel.
- Use the dkms install command to reinstall any previous module version.

depmod....

DKMS: uninstall completed.

------------------------------
Deleting module version: 0.1.82
completely from the DKMS tree.
------------------------------
Done.
Loading new sysdig-0.1.82 DKMS files...
Building for 3.11.0-12-generic and 3.13.0-24-generic
Module build for the currently running kernel was skipped since the
kernel source for this kernel does not seem to be installed.
Building initial module for 3.13.0-24-generic
Done.

sysdig-probe:
Running module version sanity check.
- Original module
- No original module exists within this kernel
- Installation
- Installing to /lib/modules/3.13.0-24-generic/updates/dkms/

depmod....

DKMS: install completed.

Danach kann dann sysdig auch schon benutzt werden.
Hier ein Beispiel: „Zeige alle Prozesse, die auf Dateien in /etc zugreifen“

sudo sysdig evt.type=open and fd.name contains /etc

Die Ausgabe sieht z.B. dann so aus:

208208 13:10:12.791863631 0 DNS (4278) < open fd=73(/etc/hosts) name=/etc/hosts flags=1(O_RDONLY) mode=0 
208307 13:10:12.792037164 3 DNS (4283) < open fd=74(/etc/hosts) name=/etc/hosts flags=1(O_RDONLY) mode=0 
444807 13:10:27.793785895 0 DNS (5019) < open fd=72(/etc/hosts) name=/etc/hosts flags=1(O_RDONLY) mode=0 
470806 13:10:32.317263671 1 gnome-settings- (3411) < open fd=19(/etc/fstab) name=/etc/fstab flags=1(O_RDONLY) mode=0 
546476 13:10:42.794281200 2 DNS (4278) < open fd=72(/etc/hosts) name=/etc/hosts flags=1(O_RDONLY) mode=0 

Auch kann man mal eben schnell schauen wer am meisten Netzwerkbandbreite braucht:

sudo sysdig -c topprocs_net

Beispielausgabe:

Bytes     Process   
------------------------------
23.82KB   Socket
546B      dnsmasq
239B      pidgin
215B      DNS

(Socket ist hier der Firefox, der eine Webseite lädt.)

Das ist extrem praktische für diverse Diagnosen. Ein interessantes Beispiel für den Einsatz liefert der Blog-Post der Entwickler, die dabei im Nachhinein analysieren, was bei einem Einbruch in einen Honeypot-Server passierte: http://draios.com/fishing-for-hackers/

Viele weitere Beispiele (IO, CPU, Security…) finden sich auf dieser Seite: https://github.com/draios/sysdig/wiki/Sysdig%20Examples

Tastatureingabe für crypt-setup nach Kernel Update / 14.04

Geschrieben von everflux am Mai 17th, 2014

Nach dem Update auf den neuesten Kernel unter Ubuntu 14.04 funktionierte bei mir die Tastatureingabe nicht mehr beim Booten. Das ist deswegen relevant, weil ich zu dem Zeitpunkt das Passwort der Festplatten-Verschlüsselung angeben muss.
Dazu gibt es auch Bugs bei Canonical, die verschiedene Workarounds vorschlagen. In meinem Fall hat jedoch gereicht, dass ich ein Paket zusätzlich installiere, dass die benötigten USB und Tastaturtreiber für die initiale Ramdisk zur Verfügung stellt:


sudo apt-get install linux-image-extra-3.13.0-24-generic
sudo update-initramfs -u

Vagrant + Nginx/Apache: Korrupte Daten bei statischen Dateien

Geschrieben von everflux am Dezember 7th, 2013

Das hat echt eine Weile gedauert dieses Yak zu shaven: Dank Vagrant und VirtualBox habe ich ein Web-Projekt mit einer leicht zu startenden Entwicklungsumgebung versehen.

Das hat vorher auch schon prima geklappt, und das Verfahren hat sich bewährt – besonders, wenn das Setup etwas komplexer ist, oder es Entwickler gibt die nicht mit Linux/Debian/Ubuntu arbeiten. Jedoch hat mich heute ein Bug gequält den ich wirklich einige Stunden suchen durfte. Alles fing damit an, dass es JavaScript Fehler hagelte.

Uncaught SyntaxError: Unexpected token ILLEGAL

Jedoch nur, wenn die Datei aus Vagrant per nginx ausgeliefert wurde. Mit Netbeans und dem eingebauten mini-Webserver für HTML5 Projekte lief alles super.

Eine Google Suche brachte unglaublich viele Ergebnisse – jedoch keine Lösung. Man solle nach bösen Zeichen schauen, am besten nach Whitespace das komisch ist. Eine super Chance auf den Holzweg abzubiegen und da eine Weile unterwegs zu sein.

Die Quellcode-Ansicht von Firefox brachte dann erstaunliches zu Tage:

Screenshot from 2013-12-07 21:30:49

Das sieht in der Tat kaputt aus. Mal schnell im Editor schauen – nein da ist alles gut. Auf der Vagrant Maschine nachschauen, auch da alles in Ordnung. (Sowas in der Art hatte ich schonmal wenn die Guest-Additions von VirtualBox nicht mehr so recht zur Umgebung passen. Aber das war hier nicht der Fall.)

Auch das Einfügen von dummy-Text änderte weder etwas an dem Muell am Ende der Datei, noch wurde der Text angezeigt. Nanu, was kann das sein? Schnell noch einen Holzweg her! „Ist bestimmt Caching.“

Das Rätsels Lösung ist dann ein 5 Jahre alter Bug in VirtualBox, wohl auch bei Apache oder sogar Versionsverwaltungssoftware zuschlagen kann: VirtualBox hat Probleme mit direktem mmap zwischen zwei Filehandles, wenn es sich dabei um per vboxfs gemountete Verzeichnisse handelt.

Hier das Ticket dazu: https://www.virtualbox.org/ticket/819

Bei nginx kann man sendfile sehr einfach ausschalten:

sendfile off;

Danach klappt alles wie erwartet.

Multi-Core vs. Single-Core: Load Testing unter Linux

Geschrieben von everflux am Juni 29th, 2013

Inzwischen sind multi-core oder sogar multi-CPU Maschinen weit verbreitet. Um etwas besser abschätzen zu können, wie gut eine Anwendung mit steigender Anzahl von CPU (Kernen) skaliert, möchte man manchmal eine Anwendung auf einzelne Kerne oder sogar einen einzigen beschränken.
Auch fuer den Fall, dass man den selben Rechner als Test-Agent und zur Ausführung des Tests (also client und server) verwenden möchte, kann es sich lohnen die zu testende Anwendung und den Test-Agenten mit beschränkten Ressourcen zu starten, damit diese nicht so stark miteinander konkurrieren.
Unter Linux (Ubuntu, Debian, Arch…) gibt es das Utility „taskset“. Damit kann die CPU Affinität eines Prozesses beim start oder sogar nachträglich eingestellt werden.
Beispielsweise kann man damit dann eine Java Webanwendung folgendermaßen auf einen Core begrenzen:

taskset 1 [start-kommando]

In meinem Fall nutze ich jmeter um gegen eine so gestartete Anwendung zu testen:

env MAVEN_OPTS="$MAVEN_OPTS -noverify" taskset 1 mvn -Dspring.profiles.active=dev jetty:run

Schon beim Start bemerkt man recht deutlich, wie gut Java von Mehrprozessorarchitekturen profitiert. Selbst wenn die eigene Anwendung nicht stark parallelisert ist.

nginx: SSL mit Perfect-Forward-Secrecy und SPDY unter Ubuntu

Geschrieben von everflux am Juni 27th, 2013

Es gibt SSL und es gibt SSL mit Perfect-Forward-Secrecy (PFS). Der Unterschied: Bei perfect forward secrecy kann durch den Verlust des privaten Schlüssels nicht im Nachhinein aufgezeichnete Kommunikation der Vergangenheit entschlüsselt werden. Der Grund liegt darin, dass der zufällige Sitzungsschlüssel nicht zwischen den Parteien mittels public-key-cryptography versendet wird, sondern mit einem speziellen Verfahren berechnet wird. Bei diesem Diffie-Hellmann-Schlüsselaustausch berechnen beide Parteien gemeinsam einen Sitzungsschlüssel. Der private Schlüssel hilft später nicht den Sitzungsschlüssel zu erlangen, jeder Sitzungsschlüssel muss einzeln mit speziellen Verfahren gebrochen werden, was aufwendig ist.

Damit Besucher einer Webseite keine Warnung des Browsers erhalten, weil dem Zertifikat der Webseite nicht vertraut wird, empfiehlt es sich, das Zertifikat von einer CA signieren zu lassen, die von den Browserherstellern unterstützt wird.
Ein Anbieter kostenloser Zertifikate ist „StartSSL“: http://www.startssl.com/

Wenn man lediglich SSL und perfect-forward-security mit nginx konfigurieren moechte, funktioniert dich bereits mit Ubuntu 12.04 Precise (LTS). Fuer SPDY reicht das alleine nicht: Die OpenSSL Version ist nicht aktuell genug und nginx ist nicht mit dem Modul kompiliert worden. Aber dazu gibt es ein PPA 🙂

Erster Schritt: SSL Zertifikat besorgen. Mit diesem Aufruf (www.server.com durch die korrekte Domain ersetzen) erzeugt man die nötigen Dateien (private key und certificate signing request).

openssl req -nodes -newkey rsa:4096 -nodes -keyout myserver.key -out server.csr \
-subj "/C=DE/ST=State/L=City/O=Company/OU=IT/CN=www.server.com"

Zweiter Schritt: Bei StartSSL signieren lassen. Das Ergebnis speichert man in der Datei „www.example.com.pem“.

Dritter Schritt: CA Zertifikat herunterladen

wget http://www.startssl.com/certs/sub.class1.server.ca.pem
wget http://www.startssl.com/certs/ca.pem

Vierter Schritt: Wir erzeugen eine Datei mit den Diffie-Hellmann-Parametern

openssl dhparam -rand - 1024 > dhparam.pem

Fünfter Schritt: Alles zu einer certificate-chain vereinigen.

cat ww*.pem dhparam.pem sub.class1.server.ca.pem ca.pem > www.example.com.chain.pem

Sechster Schritt: Konfiguration von nginx mit SSL – die IP 1.2.3.4 ersetzt man durch die korrekte.

server {
#your IP here
listen 1.2.3.4:443;
server_name www.example.com;
#ssl
ssl on;
ssl_certificate /etc/nginx/ssl/example.com.chain.pem;
ssl_certificate_key /etc/nginx/ssl/example.com.key;
#PFS
ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
ssl_prefer_server_ciphers On;
ssl_ciphers ECDHE-RSA-AES128-SHA256:AES128-GCM-SHA256:RC4:HIGH:!MD5:!aNULL:!EDH;
...
}

Fertig bis auf SPDY Support. Das ganze kann man mit dem SSL Check Tool von https://www.ssllabs.com/ssltest/ zusätzlich auf korrekte Konfiguration prüfen.

Für SPDY Support geht es so weiter:
Installation einer nginx Version mit SPDY Support die statisch gegen OpenSSL gelinkt ist, so dass NPN Support (Next protocol negotiation) funktioniert, auch wenn Ubuntu 12.04 eigentlich mit einem älteren OpenSSL kommt.

sudo add-apt-repository ppa:chris-lea/nginx-devel
sudo apt-get update
sudo apt-get install nginx-full

nginx Konfiguration anpassen:

server {
...
listen 443 ssl spdy default_server;
...
}

Damit auch User, die nicht per SSL auf die Seite zugreifen SPDY erkennen und umschalten, kann man noch diesen Header setzen:


add_header Alternate-Protocol 443:npn-spdy/2;

Als Performance Verbesserung kann noch diese Option zur Aktivierung von OCSP Stapling verwendet werden:

#google public dns
resolver 8.8.8.8;
ssl_stapling on;
ssl_trusted_certificate ssl/www.example.com.chain.pem;

Leider ist mit der Apache Version, die derzeit mit Ubuntu ausgeliefert wird, kein performantes perfect forward secrecy möglich. Der Apache http in der (uralt) Version hat keine Unterstützung für elliptic curve cryptography mit der die gemeinsame Berechnung eines Sitzungsschlüssels schnell und ressourcenschonend möglich ist.
Es gibt zwar andere Algorithmen die mittels Diffie-Hellmann PFS realisieren und auch mit dem Apache httpd funktionieren, jedoch sind diese für größere Webseiten nicht ohne zusätzliche Hardware praktikabel.

Ubuntu boot partition voll

Geschrieben von everflux am September 14th, 2012

Wenn Ubuntu sich beklagt, dass die boot Partion bald voll ist, dann muss man etwas unternehmen.

Das ist eigentlich sogar sehr einfach!

Die boot Partition beinhaltet den Kernel (das Betriebssystem) und eine RAM-Disk, auf der Treiber und minimale Start-Scripte liegen. Diese werden benötigt, um Treiber und spezielle Geräte wie eine verschlüsselte Startpartion einzurichten.

Nun kann der Speicher, der für diese Dinge benötigt wird, sehr stark wachsen. Vor allem wenn viele Kernel-Updates herausgegeben werden, oder man Virtualbox oder NVIDIA Treiber installiert hat, die viel Speicherplatz benötigen. Wenn man sicher ist, dass mit dem aktuellen Kernel alles funktionier, dann kann man getrost alte Linux Kernel Installationen entfernen um Speicherplatz auf der boot Partition zu sparen.

Ich mache das folgendermaßen:

Termial öffnen

sudo apt-get purge linux-image<tab><tab>

Nun erhält man verschiedene Versionen zur Auswahl.  Ich nehme dann immer alle bis auf die neuesten drei. So kann man bei Problemen nochmal eine Version zurück gehen.

Zum Beispiel entferne ich dann folgende Kernel um auf der boot Partition mehr freien Speicherplatz zu schaffen:


sudo apt-get purge linux-image-3.2.0-23-generic linux-image-3.2.0-24-generic linux-image-3.2.0-25-generic linux-image-3.2.0-26-generic linux-image-3.2.0-27-generic

Analog für die „headers“ und andere Image Pakete.

Schon ist Platz für neue Ubuntu Updates, Kernel Updates und Module wie Virtualbox oder proprietäre Grafiktreiber wie NVIDIA.

Ubuntu 12.04: OpenJDK selber bauen

Geschrieben von everflux am Mai 12th, 2012

Ubuntu ist für mich die präferierte Entwicklungsplattform, sicherlich geht es vielen anderen (Java) Softwareentwicklern ähnlich. Und im Sinne von OpenSource möchte man OpenJDK auch auf dem eigenen Rechner übersetzen können. Das ist z.B. nützlich, wenn man selber das Java mal patchen oder debuggen möchte, aber auch um z.B. die neuesten Entwicklungen von Java 8 auf dem eigenen System ausprobieren zu können.

Im Vergleich zu früher macht der Übergang von Ubuntu zu MultiArch auf 64 bit Systemen etwas Probleme, jedoch ist das mit einem „gewusst wie“ schnell erledigt. Als Vorbedingung muss ein Java (OpenJDK 6/7, Oracle JDK) installiert sein. Ich habe in meinem Fall unter /usr/lib/jvm/jdk1.7.0 ein Oracle JDK installiert.

Als nächstes benötigt man Mercurial, die hgforest extension und ein paar Bibliotheken für den Build. Ich installiere hgforest im Home-Verzeichnis, wer das nicht mag, muss die Pfade entsprechend anpassen:

apt-get install mercurial
apt-get install gawk g++ libcups2-dev libasound2-dev libfreetype6-dev libx11-dev libxt-dev libxext-dev libxrender-dev libxtst-dev libfontconfig1-dev
hg clone https://bitbucket.org/pmezard/hgforest-crew/overview/ "$HOME/hgforest"

Die hgforest Erweiterung fuer Mercurial traegt man direkt in der Mercurial Konfiguration ein, indem man die Datei ~/.hgrc editiert und folgenden Abschnitt ergaenzt (auch hier gilt dann ggf. den Pfad anzupassen)

[extensions]
forest=~/hgforest/forest.py

Nun clont man die OpenJDK Sourcen aus dem Updates-Repository für OpenJDK 7:

hg fclone http://hg.openjdk.java.net/jdk7u/jdk7u openjdk7u

Dazu solle man ca. ein Gigabyte Speicher auf der Festplatte einplanen. Bei dem ersten Build sollte auch eine Internet Verbindung vorhanden sein, da ggf. noch zusätzliche Libraries nachgeladen werden. Nun starten wir den Build:

cd openjdk7u
unset JAVA_HOME
export LANG=C
export ALT_BOOTDIR="/usr/lib/jvm/jdk1.7.0"
export ALLOW_DOWNLOADS=true
export EXTRA_LIBS=/usr/lib/x86_64-linux-gnu/libasound.so.2
make sanity && time make

Zu beachten ist hier, dass die Environment-Variablen „ALLOW_DOWNLOADS“ und „EXTRA_LIBS“ gesetzt sind. Letztere rührt daher, dass auf 64 Bit Systemen mit Ubuntu das OpenJDK Build-System die Libraries (noch) nicht von selbst richtig findet. Auf 32 bit Systemen wird das nicht nötig sein, und vermutlich auch in zukünftigen OpenJDK Versionen direkt implementiert sein.

Der Build Output sollte in etwa so aussehen:

########################################################################
##### Build time 00:10:30 jdk for target(s) sanity all docs images #####
########################################################################


#-- Build times ----------
Target all_product_build
Start 2012-05-12 11:40:32
End   2012-05-12 12:04:01
00:01:27 corba
00:10:15 hotspot
00:00:18 jaxp
00:00:27 jaxws
00:10:30 jdk
00:00:32 langtools
00:23:29 TOTAL
-------------------------


real    23m30.532s
user    32m10.625s
sys    2m24.617s

Im Ordner „build“ befindet sich dann der Ordner „linux-amd64“ in dem sich das frisch kompilierte Java auch ausführen lässt:

./build/linux-amd64/bin/java -version
openjdk version "1.7.0-internal"
OpenJDK Runtime Environment (build 1.7.0-internal-tkruse_2012_05_12_11_40-b00)
OpenJDK 64-Bit Server VM (build 23.0-b21, mixed mode)
Übrigens lässt sich genauso einfach auch Java 8 (OpenJDK 8 ) auf einem Debian oder Ubuntu System übersetzen, das Repository ist unter http://hg.openjdk.java.net/jdk8/jdk8/ zu finden.


http://everflux.de/
Copyright © 2007, 2008 everflux. Alle Rechte vorbehalten. All rights reserved.