cat /proc/cpuinfo

cat /proc/meminfo

Eine mögliche Ausgabe für cpuinfo wäre z.B:

processor	: 0
vendor_id	: AuthenticAMD
cpu family	: 16
model		: 4
model name	: AMD Phenom(tm) II X2 550 Processor
stepping	: 3
cpu MHz		: 3115.722
cache size	: 512 KB
physical id	: 0
siblings	: 1
core id		: 0
cpu cores	: 1
apicid		: 0
initial apicid	: 1
fpu		: yes
fpu_exception	: yes
cpuid level	: 5
wp		: yes
flags		: fpu de tsc msr pae cx8 apic cmov pat clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt lm 3dnowext 3dnow constant_tsc up rep_good pni cx16 popcnt lahf_lm cmp_legacy extapic cr8_legacy abm sse4a misalignsse 3dnowprefetch
bogomips	: 6235.57
TLB size	: 1024 4K pages
clflush size	: 64
cache_alignment	: 64
address sizes	: 48 bits physical, 48 bits virtual
power management: ts ttp tm stc 100mhzsteps hwpstate

Viel Spaß damit

Um nun dem “Problem” engegenzuwirken, gibt es einige Einstellungen, die einen Betrieb nach dem Logout ermöglichen. Zum einen fügt man in der Datei

bin/asadmin

die Option -Xrs zum Java Startkommando hinzu. Die Datei findet man im bin Ordner der GlassFish-Installation. Bei Windows heisst diese am Ende .bat. Die Zeile, die man verändert, sollte in etwa so aussehen (hier ist der Xrs Parameter schon hinzugefügt)

%JAVA% -Xrs -jar "%~dp0..\glassfish\modules\admin-cli.jar" %*

Im nächsten Schritt müssen wir noch in der domain.xml (in der jeweiligen Domain, genauer im Ordner) ebenfalls genau diesen Parameter setzen. Danach einfach wie gewohnt den Server starten und ausloggen

Zunächst brauchen wir ein frisches, neues Repository, mit dem wir arbeiten möchten/wollen/sollen. Ich nehme an, dass der versierte Leser den umgang mit einem Konsolentool beherrscht (hier ist speziell die Rede von Ubuntu und dem Teminal). Zudem setze ich voraus, dass ein vServer (oder ein ähnlicher Server, z.B. root-Server oder ein Heimserver) vorhanden ist, auf den ihr root Zugriff habt.

Da Git das Tool der Wahl ist, brauchen wir es sowohl auf dem Host-System (auch Remote genannt) als auch auf dem Client (z.B. euer lokaler Rechner). Ich führe das Beispiel vor, wenn euer Host System ein Heimserver ist mit der IP 192.168.1.102 und dem Benutzernamen “hostuser”

Um Git lokal (Ubuntu 10.04 oder 10.10, oder was ihr mögt…) nutzen zu können, müssten wir es installieren. Das geschieht mit folgendem Befehl:

sudo apt-get install git-core

Im zweiten Schritt loggen wir uns per SSH auf dem Host-System unter dem Benutzernamen hostuser ein und installieren auch hier Git:

ssh hostuser@192.168.1.102
sudo apt-get install git-core

Repositories lege ich (persönlich) gerne strukturiert im repos Ordner im Home-Folder des Benutzers ein. Aber das ist jedem selbst überlassen, hier gibt es keine speziellen Vorgaben:

mkdir -p /home/hostuser/repos

Nun wechseln wir in das Verzeichnis, um hier ein Repository zu erstellen (ja, es ist die Langvariante, für alle Besserwisser *g* ):

cd /home/hostuser/repos

Ein Repository ist bei Git im Grunde nur ein Verzeichnis, welches Git informationen enthält. Ich nehme hier an, dass wir ein PHP Projekt starten möchten, also erstellen wir zunächst ein Verzeichnis und wechseln zu direkt zu diesem:

mkdir php.myproject.git
cd php.myproject.git

Die Namensgebung ist auch hier nur eine Vorliebe von mir. Es ist jedem selbst überlassen, wie man das Verzeichnis benennt. In dem Verzeichnis selbst initiieren wir ein leeres Git repo.

git init --bare --share

Damit haben wir schon einene großen teil geschafft. Nun loggen wir uns mit dem “exit” oder “logout” befehl wieder aus, sodass wir nun auf dem lokalen System dieses erzeugte Repository clonen können. Dies geschieht wie folgt (wohlgemerkt auf dem lokalen Rechner, nicht auf dem Server):

git clone ssh://hostuser@192.168.1.102/home/hostuser/repos/php.myproject.git php.myproject.git

Falls alles wie geplant funktioniert hat, solltet ihr eine Passwortabfrage erhalten (wenn der Zugang zum server vernünftig gesichert ist). Im hinteren Teil des Befehls seht ihr das Zielverzeichnis in das geclont wird (euer lokales Repository). Nun wechseln wir in dieses Verzeichnis und führen…

git status

…aus. Hier solltet ihr einige erste Informationen zum lokalen repo bekommen. Damit sind wir eigentlich schon fertig und können mit dem Repository arbeiten. Nun kann man noch einige interessante Dinge ausprobieren. Mit…

git branch -r

… erfahrt ihr, welche branches euer Remote-Repository zur Verfügung hat. Um einen neuen Branch (lokal) zu eröffnen, führt man git branch aus, in etwa so:

git branch v1.0.0

Hier habe ich meinen neuen Branch v1.0.0 benannt. Wie ihr den Branch benennt ist auch hier eurer Phantasie überlassen. Mit git checkout wechselt man zu diesem neuen Branch:

git checkout v1.0.0

Um diesen Branch nun auch auf das Remote System zu bringen, kann man ganz einfach folgenden gut Befehl verwenden:

git push origin v1.0.0

Damit wird der Branch in euer “zentrales” Repo geschoben (damit auch andere diesen zur Verfügung haben).

EInige Bedenken gegenüber Google Analytics brachten mich dazu Piwik anzutesten. Was genau sprcht also zunächst gegen Google? Der dickste Punkt wird wohl die Tatsache sein, dass GA-Daten auf dem Server von Google weilen. Damit gibt man seine User-Daten an Dritte weiter. Was Google nun mit diesen Daten anfängt, wird wohl niemand (außer Google) genau sagen können. In jedem Fall muss man seine User auf die Nutzung von GA hinweisen und diese müssen entsprechend zustimmen. Einfacher ist es hier bei Piwik, da man Daten auf dem eigenen Server behält (was die Nutzungsbedingungen für den User vereinfach: Keine Weitergabe an Dritte)

Zusätzlich ist gibt es mittlerweile GA-Blocker, die natürlich auch für Ungenauigkeiten sorgen. Bei Piwik wäre dies auch möglich, ist jedoch bisher noch bei sehr sehr wenigen bekannt. Auch weiß bisher keiner, ob Google die Daten für die Rankings bei den Suchmaschinen verwendet oder eben nicht. Ich persönlich tendiere zum Ersteren.

Nun einiges zu Piwik: Das Tool wird auf dem eigenen Server installiert und das Script sendet keinerlei Daten an Dritte. Zudem erstellt Piwik Live-Statistiken und verfügt über eine API, die es Entwicklern erlaubt, eigene Plug-ins zu entwickeln und auf die Daten zuzugreifen. Dies hat den Vorteil, dass man Daten auch evtl. auf der Webseite oder in Admin-Bereichen anzeigen kann.

Nachteile habe ich bisher recht wenige festgestellt, jedoch seien diese hier der Vollständigkeit erwähnt. Bei 10 parallel laufenden Seiten ist der Admin-Bereich mittlerweile recht langsam geworden. Da werde ich wohl nicht um eine Aufrüstung der Hardware bzw. Auslagerung der Statistiken auf einen separaten Server umher kommen. Ab und an gibt es auch noch die Meldung “Internal Server Error”, was nervig ist, aber mit einem Reload (meist) schnell aus der Welt geschafft ist. Leider habe ich im Vergleich mit GA auch nicht dieselben Daten erhalten. GA hat stets mehr getrackt als Piwik. Dies kann natürlich auch mit Lastproblemen meines Servers zusammenhängen.

Noch ein kleines Schlußwort: Ich habe mich entschlossen meine Projekte zunächst von Google Analytics zu befreien und bin guter Dinge, dass Piwik stets weiter entwickelt wird und entsprechend entsprechend verbessert wird.